@oxyhq/bloom 0.3.4 → 0.3.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/lib/commonjs/theme/set-color-scheme-safe.js +34 -12
- package/lib/commonjs/theme/set-color-scheme-safe.js.map +1 -1
- package/lib/module/theme/set-color-scheme-safe.js +34 -12
- package/lib/module/theme/set-color-scheme-safe.js.map +1 -1
- package/lib/typescript/commonjs/theme/set-color-scheme-safe.d.ts +27 -9
- package/lib/typescript/commonjs/theme/set-color-scheme-safe.d.ts.map +1 -1
- package/lib/typescript/module/theme/set-color-scheme-safe.d.ts +27 -9
- package/lib/typescript/module/theme/set-color-scheme-safe.d.ts.map +1 -1
- package/package.json +1 -1
- package/src/theme/set-color-scheme-safe.ts +36 -12
|
@@ -7,15 +7,33 @@ exports.setColorSchemeSafe = setColorSchemeSafe;
|
|
|
7
7
|
var _reactNative = require("react-native");
|
|
8
8
|
/**
|
|
9
9
|
* Safely set the color scheme via Appearance API.
|
|
10
|
-
* On Android (RN 0.83+), Appearance.setColorScheme has a Kotlin non-null
|
|
11
|
-
* annotation on `style`. Passing null for 'system' crashes.
|
|
12
|
-
* Workaround: resolve the system preference and pass 'light'/'dark' instead.
|
|
13
10
|
*
|
|
14
|
-
*
|
|
15
|
-
*
|
|
16
|
-
*
|
|
17
|
-
*
|
|
18
|
-
*
|
|
11
|
+
* Behavior by mode:
|
|
12
|
+
* - 'light' / 'dark': set the explicit override.
|
|
13
|
+
* - 'system' / 'adaptive': leave the OS in control. We must NOT call
|
|
14
|
+
* Appearance.setColorScheme(resolved) here — doing so installs an
|
|
15
|
+
* app-level override that masks the OS preference. Once that override
|
|
16
|
+
* is set, useColorScheme() / Appearance.getColorScheme() return the
|
|
17
|
+
* frozen override instead of the live OS value, and the app stops
|
|
18
|
+
* following dark↔light OS toggles until a cold restart.
|
|
19
|
+
*
|
|
20
|
+
* On iOS we additionally pass 'unspecified' to clear any prior
|
|
21
|
+
* override that may have been installed by a previous explicit mode.
|
|
22
|
+
* 'unspecified' is the documented sentinel that tells the native
|
|
23
|
+
* Appearance module to fall back to the OS preference. (RN's JS
|
|
24
|
+
* implementation forwards this straight through to the native
|
|
25
|
+
* bridge; on iOS this clears the override.)
|
|
26
|
+
*
|
|
27
|
+
* On Android (RN 0.83+) the native Kotlin signature has @NonNull on
|
|
28
|
+
* `style` and rejects null, and 'unspecified' is not honored as a
|
|
29
|
+
* clear-override sentinel on Android either. As a result, if a user
|
|
30
|
+
* previously selected 'light' or 'dark' and then switches back to
|
|
31
|
+
* 'system' on Android, the override remains until the next cold
|
|
32
|
+
* restart. Users who never explicitly overrode are unaffected because
|
|
33
|
+
* we never install an override in system mode in the first place.
|
|
34
|
+
*
|
|
35
|
+
* On react-native-web, Appearance.setColorScheme is not implemented at
|
|
36
|
+
* all; the browser controls the color scheme, so we bail out on web.
|
|
19
37
|
*/
|
|
20
38
|
function setColorSchemeSafe(mode) {
|
|
21
39
|
if (_reactNative.Platform.OS === 'web') {
|
|
@@ -23,10 +41,14 @@ function setColorSchemeSafe(mode) {
|
|
|
23
41
|
}
|
|
24
42
|
const effectiveMode = mode === 'adaptive' ? 'system' : mode;
|
|
25
43
|
if (effectiveMode === 'system') {
|
|
26
|
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
_reactNative.
|
|
44
|
+
// Clear any prior app-level override so useColorScheme() tracks the
|
|
45
|
+
// OS. iOS honors 'unspecified' as a sentinel to fall back to the
|
|
46
|
+
// system preference; Android does not (see note above).
|
|
47
|
+
if (_reactNative.Platform.OS === 'ios') {
|
|
48
|
+
_reactNative.Appearance.setColorScheme('unspecified');
|
|
49
|
+
}
|
|
50
|
+
return;
|
|
30
51
|
}
|
|
52
|
+
_reactNative.Appearance.setColorScheme(effectiveMode);
|
|
31
53
|
}
|
|
32
54
|
//# sourceMappingURL=set-color-scheme-safe.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"names":["_reactNative","require","setColorSchemeSafe","mode","Platform","OS","effectiveMode","
|
|
1
|
+
{"version":3,"names":["_reactNative","require","setColorSchemeSafe","mode","Platform","OS","effectiveMode","Appearance","setColorScheme"],"sourceRoot":"../../../src","sources":["theme/set-color-scheme-safe.ts"],"mappings":";;;;;;AAAA,IAAAA,YAAA,GAAAC,OAAA;AAGA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACO,SAASC,kBAAkBA,CAACC,IAAe,EAAE;EAClD,IAAIC,qBAAQ,CAACC,EAAE,KAAK,KAAK,EAAE;IACzB;EACF;EAEA,MAAMC,aAAa,GAAGH,IAAI,KAAK,UAAU,GAAG,QAAQ,GAAGA,IAAI;EAE3D,IAAIG,aAAa,KAAK,QAAQ,EAAE;IAC9B;IACA;IACA;IACA,IAAIF,qBAAQ,CAACC,EAAE,KAAK,KAAK,EAAE;MACzBE,uBAAU,CAACC,cAAc,CAAC,aAAa,CAAC;IAC1C;IACA;EACF;EAEAD,uBAAU,CAACC,cAAc,CAACF,aAAa,CAAC;AAC1C","ignoreList":[]}
|
|
@@ -3,15 +3,33 @@
|
|
|
3
3
|
import { Appearance, Platform } from 'react-native';
|
|
4
4
|
/**
|
|
5
5
|
* Safely set the color scheme via Appearance API.
|
|
6
|
-
* On Android (RN 0.83+), Appearance.setColorScheme has a Kotlin non-null
|
|
7
|
-
* annotation on `style`. Passing null for 'system' crashes.
|
|
8
|
-
* Workaround: resolve the system preference and pass 'light'/'dark' instead.
|
|
9
6
|
*
|
|
10
|
-
*
|
|
11
|
-
*
|
|
12
|
-
*
|
|
13
|
-
*
|
|
14
|
-
*
|
|
7
|
+
* Behavior by mode:
|
|
8
|
+
* - 'light' / 'dark': set the explicit override.
|
|
9
|
+
* - 'system' / 'adaptive': leave the OS in control. We must NOT call
|
|
10
|
+
* Appearance.setColorScheme(resolved) here — doing so installs an
|
|
11
|
+
* app-level override that masks the OS preference. Once that override
|
|
12
|
+
* is set, useColorScheme() / Appearance.getColorScheme() return the
|
|
13
|
+
* frozen override instead of the live OS value, and the app stops
|
|
14
|
+
* following dark↔light OS toggles until a cold restart.
|
|
15
|
+
*
|
|
16
|
+
* On iOS we additionally pass 'unspecified' to clear any prior
|
|
17
|
+
* override that may have been installed by a previous explicit mode.
|
|
18
|
+
* 'unspecified' is the documented sentinel that tells the native
|
|
19
|
+
* Appearance module to fall back to the OS preference. (RN's JS
|
|
20
|
+
* implementation forwards this straight through to the native
|
|
21
|
+
* bridge; on iOS this clears the override.)
|
|
22
|
+
*
|
|
23
|
+
* On Android (RN 0.83+) the native Kotlin signature has @NonNull on
|
|
24
|
+
* `style` and rejects null, and 'unspecified' is not honored as a
|
|
25
|
+
* clear-override sentinel on Android either. As a result, if a user
|
|
26
|
+
* previously selected 'light' or 'dark' and then switches back to
|
|
27
|
+
* 'system' on Android, the override remains until the next cold
|
|
28
|
+
* restart. Users who never explicitly overrode are unaffected because
|
|
29
|
+
* we never install an override in system mode in the first place.
|
|
30
|
+
*
|
|
31
|
+
* On react-native-web, Appearance.setColorScheme is not implemented at
|
|
32
|
+
* all; the browser controls the color scheme, so we bail out on web.
|
|
15
33
|
*/
|
|
16
34
|
export function setColorSchemeSafe(mode) {
|
|
17
35
|
if (Platform.OS === 'web') {
|
|
@@ -19,10 +37,14 @@ export function setColorSchemeSafe(mode) {
|
|
|
19
37
|
}
|
|
20
38
|
const effectiveMode = mode === 'adaptive' ? 'system' : mode;
|
|
21
39
|
if (effectiveMode === 'system') {
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
40
|
+
// Clear any prior app-level override so useColorScheme() tracks the
|
|
41
|
+
// OS. iOS honors 'unspecified' as a sentinel to fall back to the
|
|
42
|
+
// system preference; Android does not (see note above).
|
|
43
|
+
if (Platform.OS === 'ios') {
|
|
44
|
+
Appearance.setColorScheme('unspecified');
|
|
45
|
+
}
|
|
46
|
+
return;
|
|
26
47
|
}
|
|
48
|
+
Appearance.setColorScheme(effectiveMode);
|
|
27
49
|
}
|
|
28
50
|
//# sourceMappingURL=set-color-scheme-safe.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"names":["Appearance","Platform","setColorSchemeSafe","mode","OS","effectiveMode","
|
|
1
|
+
{"version":3,"names":["Appearance","Platform","setColorSchemeSafe","mode","OS","effectiveMode","setColorScheme"],"sourceRoot":"../../../src","sources":["theme/set-color-scheme-safe.ts"],"mappings":";;AAAA,SAASA,UAAU,EAAEC,QAAQ,QAAQ,cAAc;AAGnD;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA;AACA,OAAO,SAASC,kBAAkBA,CAACC,IAAe,EAAE;EAClD,IAAIF,QAAQ,CAACG,EAAE,KAAK,KAAK,EAAE;IACzB;EACF;EAEA,MAAMC,aAAa,GAAGF,IAAI,KAAK,UAAU,GAAG,QAAQ,GAAGA,IAAI;EAE3D,IAAIE,aAAa,KAAK,QAAQ,EAAE;IAC9B;IACA;IACA;IACA,IAAIJ,QAAQ,CAACG,EAAE,KAAK,KAAK,EAAE;MACzBJ,UAAU,CAACM,cAAc,CAAC,aAAa,CAAC;IAC1C;IACA;EACF;EAEAN,UAAU,CAACM,cAAc,CAACD,aAAa,CAAC;AAC1C","ignoreList":[]}
|
|
@@ -1,15 +1,33 @@
|
|
|
1
1
|
import type { ThemeMode } from './types';
|
|
2
2
|
/**
|
|
3
3
|
* Safely set the color scheme via Appearance API.
|
|
4
|
-
*
|
|
5
|
-
*
|
|
6
|
-
*
|
|
7
|
-
*
|
|
8
|
-
*
|
|
9
|
-
*
|
|
10
|
-
* Appearance.getColorScheme()
|
|
11
|
-
*
|
|
12
|
-
*
|
|
4
|
+
*
|
|
5
|
+
* Behavior by mode:
|
|
6
|
+
* - 'light' / 'dark': set the explicit override.
|
|
7
|
+
* - 'system' / 'adaptive': leave the OS in control. We must NOT call
|
|
8
|
+
* Appearance.setColorScheme(resolved) here — doing so installs an
|
|
9
|
+
* app-level override that masks the OS preference. Once that override
|
|
10
|
+
* is set, useColorScheme() / Appearance.getColorScheme() return the
|
|
11
|
+
* frozen override instead of the live OS value, and the app stops
|
|
12
|
+
* following dark↔light OS toggles until a cold restart.
|
|
13
|
+
*
|
|
14
|
+
* On iOS we additionally pass 'unspecified' to clear any prior
|
|
15
|
+
* override that may have been installed by a previous explicit mode.
|
|
16
|
+
* 'unspecified' is the documented sentinel that tells the native
|
|
17
|
+
* Appearance module to fall back to the OS preference. (RN's JS
|
|
18
|
+
* implementation forwards this straight through to the native
|
|
19
|
+
* bridge; on iOS this clears the override.)
|
|
20
|
+
*
|
|
21
|
+
* On Android (RN 0.83+) the native Kotlin signature has @NonNull on
|
|
22
|
+
* `style` and rejects null, and 'unspecified' is not honored as a
|
|
23
|
+
* clear-override sentinel on Android either. As a result, if a user
|
|
24
|
+
* previously selected 'light' or 'dark' and then switches back to
|
|
25
|
+
* 'system' on Android, the override remains until the next cold
|
|
26
|
+
* restart. Users who never explicitly overrode are unaffected because
|
|
27
|
+
* we never install an override in system mode in the first place.
|
|
28
|
+
*
|
|
29
|
+
* On react-native-web, Appearance.setColorScheme is not implemented at
|
|
30
|
+
* all; the browser controls the color scheme, so we bail out on web.
|
|
13
31
|
*/
|
|
14
32
|
export declare function setColorSchemeSafe(mode: ThemeMode): void;
|
|
15
33
|
//# sourceMappingURL=set-color-scheme-safe.d.ts.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"set-color-scheme-safe.d.ts","sourceRoot":"","sources":["../../../../src/theme/set-color-scheme-safe.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,SAAS,CAAC;AAEzC
|
|
1
|
+
{"version":3,"file":"set-color-scheme-safe.d.ts","sourceRoot":"","sources":["../../../../src/theme/set-color-scheme-safe.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,SAAS,CAAC;AAEzC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,SAAS,QAkBjD"}
|
|
@@ -1,15 +1,33 @@
|
|
|
1
1
|
import type { ThemeMode } from './types';
|
|
2
2
|
/**
|
|
3
3
|
* Safely set the color scheme via Appearance API.
|
|
4
|
-
*
|
|
5
|
-
*
|
|
6
|
-
*
|
|
7
|
-
*
|
|
8
|
-
*
|
|
9
|
-
*
|
|
10
|
-
* Appearance.getColorScheme()
|
|
11
|
-
*
|
|
12
|
-
*
|
|
4
|
+
*
|
|
5
|
+
* Behavior by mode:
|
|
6
|
+
* - 'light' / 'dark': set the explicit override.
|
|
7
|
+
* - 'system' / 'adaptive': leave the OS in control. We must NOT call
|
|
8
|
+
* Appearance.setColorScheme(resolved) here — doing so installs an
|
|
9
|
+
* app-level override that masks the OS preference. Once that override
|
|
10
|
+
* is set, useColorScheme() / Appearance.getColorScheme() return the
|
|
11
|
+
* frozen override instead of the live OS value, and the app stops
|
|
12
|
+
* following dark↔light OS toggles until a cold restart.
|
|
13
|
+
*
|
|
14
|
+
* On iOS we additionally pass 'unspecified' to clear any prior
|
|
15
|
+
* override that may have been installed by a previous explicit mode.
|
|
16
|
+
* 'unspecified' is the documented sentinel that tells the native
|
|
17
|
+
* Appearance module to fall back to the OS preference. (RN's JS
|
|
18
|
+
* implementation forwards this straight through to the native
|
|
19
|
+
* bridge; on iOS this clears the override.)
|
|
20
|
+
*
|
|
21
|
+
* On Android (RN 0.83+) the native Kotlin signature has @NonNull on
|
|
22
|
+
* `style` and rejects null, and 'unspecified' is not honored as a
|
|
23
|
+
* clear-override sentinel on Android either. As a result, if a user
|
|
24
|
+
* previously selected 'light' or 'dark' and then switches back to
|
|
25
|
+
* 'system' on Android, the override remains until the next cold
|
|
26
|
+
* restart. Users who never explicitly overrode are unaffected because
|
|
27
|
+
* we never install an override in system mode in the first place.
|
|
28
|
+
*
|
|
29
|
+
* On react-native-web, Appearance.setColorScheme is not implemented at
|
|
30
|
+
* all; the browser controls the color scheme, so we bail out on web.
|
|
13
31
|
*/
|
|
14
32
|
export declare function setColorSchemeSafe(mode: ThemeMode): void;
|
|
15
33
|
//# sourceMappingURL=set-color-scheme-safe.d.ts.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"set-color-scheme-safe.d.ts","sourceRoot":"","sources":["../../../../src/theme/set-color-scheme-safe.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,SAAS,CAAC;AAEzC
|
|
1
|
+
{"version":3,"file":"set-color-scheme-safe.d.ts","sourceRoot":"","sources":["../../../../src/theme/set-color-scheme-safe.ts"],"names":[],"mappings":"AACA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,SAAS,CAAC;AAEzC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6BG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,SAAS,QAkBjD"}
|
package/package.json
CHANGED
|
@@ -3,15 +3,33 @@ import type { ThemeMode } from './types';
|
|
|
3
3
|
|
|
4
4
|
/**
|
|
5
5
|
* Safely set the color scheme via Appearance API.
|
|
6
|
-
* On Android (RN 0.83+), Appearance.setColorScheme has a Kotlin non-null
|
|
7
|
-
* annotation on `style`. Passing null for 'system' crashes.
|
|
8
|
-
* Workaround: resolve the system preference and pass 'light'/'dark' instead.
|
|
9
6
|
*
|
|
10
|
-
*
|
|
11
|
-
*
|
|
12
|
-
*
|
|
13
|
-
*
|
|
14
|
-
*
|
|
7
|
+
* Behavior by mode:
|
|
8
|
+
* - 'light' / 'dark': set the explicit override.
|
|
9
|
+
* - 'system' / 'adaptive': leave the OS in control. We must NOT call
|
|
10
|
+
* Appearance.setColorScheme(resolved) here — doing so installs an
|
|
11
|
+
* app-level override that masks the OS preference. Once that override
|
|
12
|
+
* is set, useColorScheme() / Appearance.getColorScheme() return the
|
|
13
|
+
* frozen override instead of the live OS value, and the app stops
|
|
14
|
+
* following dark↔light OS toggles until a cold restart.
|
|
15
|
+
*
|
|
16
|
+
* On iOS we additionally pass 'unspecified' to clear any prior
|
|
17
|
+
* override that may have been installed by a previous explicit mode.
|
|
18
|
+
* 'unspecified' is the documented sentinel that tells the native
|
|
19
|
+
* Appearance module to fall back to the OS preference. (RN's JS
|
|
20
|
+
* implementation forwards this straight through to the native
|
|
21
|
+
* bridge; on iOS this clears the override.)
|
|
22
|
+
*
|
|
23
|
+
* On Android (RN 0.83+) the native Kotlin signature has @NonNull on
|
|
24
|
+
* `style` and rejects null, and 'unspecified' is not honored as a
|
|
25
|
+
* clear-override sentinel on Android either. As a result, if a user
|
|
26
|
+
* previously selected 'light' or 'dark' and then switches back to
|
|
27
|
+
* 'system' on Android, the override remains until the next cold
|
|
28
|
+
* restart. Users who never explicitly overrode are unaffected because
|
|
29
|
+
* we never install an override in system mode in the first place.
|
|
30
|
+
*
|
|
31
|
+
* On react-native-web, Appearance.setColorScheme is not implemented at
|
|
32
|
+
* all; the browser controls the color scheme, so we bail out on web.
|
|
15
33
|
*/
|
|
16
34
|
export function setColorSchemeSafe(mode: ThemeMode) {
|
|
17
35
|
if (Platform.OS === 'web') {
|
|
@@ -19,10 +37,16 @@ export function setColorSchemeSafe(mode: ThemeMode) {
|
|
|
19
37
|
}
|
|
20
38
|
|
|
21
39
|
const effectiveMode = mode === 'adaptive' ? 'system' : mode;
|
|
40
|
+
|
|
22
41
|
if (effectiveMode === 'system') {
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
26
|
-
|
|
42
|
+
// Clear any prior app-level override so useColorScheme() tracks the
|
|
43
|
+
// OS. iOS honors 'unspecified' as a sentinel to fall back to the
|
|
44
|
+
// system preference; Android does not (see note above).
|
|
45
|
+
if (Platform.OS === 'ios') {
|
|
46
|
+
Appearance.setColorScheme('unspecified');
|
|
47
|
+
}
|
|
48
|
+
return;
|
|
27
49
|
}
|
|
50
|
+
|
|
51
|
+
Appearance.setColorScheme(effectiveMode);
|
|
28
52
|
}
|