@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.
@@ -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
- * On react-native-web, Appearance.setColorScheme is not implemented at all
15
- * (it's `undefined`), which crashes with "setColorScheme is not a function".
16
- * Appearance.getColorScheme() still works on web, so reading the system
17
- * preference is fine it's only the setter that's missing. The browser /
18
- * electron controls the color scheme anyway, so we just bail out on web.
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) heredoing 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
- const resolved = _reactNative.Appearance.getColorScheme() ?? 'light';
27
- _reactNative.Appearance.setColorScheme(resolved);
28
- } else {
29
- _reactNative.Appearance.setColorScheme(effectiveMode);
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","resolved","Appearance","getColorScheme","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;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;EAC3D,IAAIG,aAAa,KAAK,QAAQ,EAAE;IAC9B,MAAMC,QAAQ,GAAGC,uBAAU,CAACC,cAAc,CAAC,CAAC,IAAI,OAAO;IACvDD,uBAAU,CAACE,cAAc,CAACH,QAAQ,CAAC;EACrC,CAAC,MAAM;IACLC,uBAAU,CAACE,cAAc,CAACJ,aAAa,CAAC;EAC1C;AACF","ignoreList":[]}
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
- * On react-native-web, Appearance.setColorScheme is not implemented at all
11
- * (it's `undefined`), which crashes with "setColorScheme is not a function".
12
- * Appearance.getColorScheme() still works on web, so reading the system
13
- * preference is fine it's only the setter that's missing. The browser /
14
- * electron controls the color scheme anyway, so we just bail out on web.
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) heredoing 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
- const resolved = Appearance.getColorScheme() ?? 'light';
23
- Appearance.setColorScheme(resolved);
24
- } else {
25
- Appearance.setColorScheme(effectiveMode);
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","resolved","getColorScheme","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,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;EAC3D,IAAIE,aAAa,KAAK,QAAQ,EAAE;IAC9B,MAAMC,QAAQ,GAAGN,UAAU,CAACO,cAAc,CAAC,CAAC,IAAI,OAAO;IACvDP,UAAU,CAACQ,cAAc,CAACF,QAAQ,CAAC;EACrC,CAAC,MAAM;IACLN,UAAU,CAACQ,cAAc,CAACH,aAAa,CAAC;EAC1C;AACF","ignoreList":[]}
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
- * On Android (RN 0.83+), Appearance.setColorScheme has a Kotlin non-null
5
- * annotation on `style`. Passing null for 'system' crashes.
6
- * Workaround: resolve the system preference and pass 'light'/'dark' instead.
7
- *
8
- * On react-native-web, Appearance.setColorScheme is not implemented at all
9
- * (it's `undefined`), which crashes with "setColorScheme is not a function".
10
- * Appearance.getColorScheme() still works on web, so reading the system
11
- * preference is fine it's only the setter that's missing. The browser /
12
- * electron controls the color scheme anyway, so we just bail out on web.
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;;;;;;;;;;;GAWG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,SAAS,QAYjD"}
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
- * On Android (RN 0.83+), Appearance.setColorScheme has a Kotlin non-null
5
- * annotation on `style`. Passing null for 'system' crashes.
6
- * Workaround: resolve the system preference and pass 'light'/'dark' instead.
7
- *
8
- * On react-native-web, Appearance.setColorScheme is not implemented at all
9
- * (it's `undefined`), which crashes with "setColorScheme is not a function".
10
- * Appearance.getColorScheme() still works on web, so reading the system
11
- * preference is fine it's only the setter that's missing. The browser /
12
- * electron controls the color scheme anyway, so we just bail out on web.
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;;;;;;;;;;;GAWG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,SAAS,QAYjD"}
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
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@oxyhq/bloom",
3
- "version": "0.3.4",
3
+ "version": "0.3.5",
4
4
  "description": "Bloom UI — Oxy ecosystem component library for React Native + Expo + Web",
5
5
  "main": "lib/commonjs/index.js",
6
6
  "module": "lib/module/index.js",
@@ -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
- * On react-native-web, Appearance.setColorScheme is not implemented at all
11
- * (it's `undefined`), which crashes with "setColorScheme is not a function".
12
- * Appearance.getColorScheme() still works on web, so reading the system
13
- * preference is fine it's only the setter that's missing. The browser /
14
- * electron controls the color scheme anyway, so we just bail out on web.
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) heredoing 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
- const resolved = Appearance.getColorScheme() ?? 'light';
24
- Appearance.setColorScheme(resolved);
25
- } else {
26
- Appearance.setColorScheme(effectiveMode);
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
  }