Remove 'unspecified' from ColorSchemeName (#56686)#56686
Open
huntie wants to merge 1 commit intofacebook:mainfrom
Open
Remove 'unspecified' from ColorSchemeName (#56686)#56686huntie wants to merge 1 commit intofacebook:mainfrom
huntie wants to merge 1 commit intofacebook:mainfrom
Conversation
meta-cla
Bot
added
the
CLA Signed
|
@huntie has exported this pull request. If you are a Meta employee, you can view the originating Diff in D102527387. |
|
Warning JavaScript API change detected This PR commits an update to
This change was flagged as: |
meta-codesync
Bot
changed the title
huntie
added a commit
to huntie/react-native
that referenced
this pull request
May 5, 2026
…k#56686) Summary: Removes `'unspecified'` from the return type of `Appearance.getColorScheme()` and `useColorScheme()`, splitting the setter input into a separate `ColorSchemeOverride` type. This resolves a longstanding misalignment between what native returns and what the types promise. **Motivation** `'unspecified'` is only meaningful as an input to `setColorScheme()` — neither iOS nor Android ever returns it from `getColorScheme()`. When `setColorScheme('unspecified')` is called, the JS layer re-queries the native module and caches the resolved system value. After this change: - `Appearance.getColorScheme()` returns `'light' | 'dark'` (no longer `'unspecified'`) - `Appearance.setColorScheme()` receives `'light' | 'dark' | 'unspecified'` Paired with docs updates: - facebook/react-native-website#5060 - facebook/react-native-website#5069 **History of this API** - The TurboModule spec originally typed these methods as plain `string` because codegen didn't support union types (T52919652). - When support landed, D63681874 upgraded to `ColorSchemeName = 'light' | 'dark' | 'unspecified'` — a type-level cleanup that inadvertently widened return types to include `'unspecified'`, a value native never returns. This caused `$FlowFixMe` suppressions across downstream callers. - D80705652 later aligned the `.d.ts` and fixed a bug where `setColorScheme('unspecified')` threw an incorrect invariant. Changelog: [General][Breaking] - `useColorScheme()` no longer returns `'unspecified'` (this was always the case, but is a breaking type change) Differential Revision: D102527387
huntie
changed the title
huntie
added a commit
to huntie/react-native
that referenced
this pull request
May 6, 2026
Summary:
Removes `'unspecified'` from the return type of `Appearance.getColorScheme()` and `useColorScheme()`, splitting the setter input into a separate `ColorSchemeOverride` type. This resolves a longstanding misalignment between what native returns and what the types promise.
**Motivation**
`'unspecified'` is only meaningful as an input to `setColorScheme()` — neither iOS nor Android ever returns it from `getColorScheme()`. When `setColorScheme('unspecified')` is called, the JS layer re-queries the native module and caches the resolved system value.
After this change:
- `Appearance.getColorScheme()` returns `'light' | 'dark'` (no longer `'unspecified'`)
- `Appearance.setColorScheme()` receives `'light' | 'dark' | 'unspecified'`
Paired with docs updates:
- facebook/react-native-website#5060
- facebook/react-native-website#5069
**History of this API**
- The TurboModule spec originally typed these methods as plain `string` because codegen didn't support union types (T52919652).
- When support landed, D63681874 upgraded to `ColorSchemeName = 'light' | 'dark' | 'unspecified'` — a type-level cleanup that inadvertently widened return types to include `'unspecified'`, a value native never returns. This caused `$FlowFixMe` suppressions across downstream callers.
- D80705652 later aligned the `.d.ts` and fixed a bug where `setColorScheme('unspecified')` threw an incorrect invariant.
Changelog:
[General][Breaking] - `useColorScheme()` no longer returns `'unspecified'` (this was always the case, but is a breaking type change)
Differential Revision: D102527387
huntie
added a commit
to huntie/react-native
that referenced
this pull request
May 6, 2026
Summary:
Removes `'unspecified'` from the return type of `Appearance.getColorScheme()` and `useColorScheme()`, splitting the setter input into a separate `ColorSchemeOverride` type. This resolves a longstanding misalignment between what native returns and what the types promise.
**Motivation**
`'unspecified'` is only meaningful as an input to `setColorScheme()` — neither iOS nor Android ever returns it from `getColorScheme()`. When `setColorScheme('unspecified')` is called, the JS layer re-queries the native module and caches the resolved system value.
After this change:
- `Appearance.getColorScheme()` returns `'light' | 'dark'` (no longer `'unspecified'`)
- `Appearance.setColorScheme()` receives `'light' | 'dark' | 'unspecified'`
Paired with docs updates:
- facebook/react-native-website#5060
- facebook/react-native-website#5069
**History of this API**
- The TurboModule spec originally typed these methods as plain `string` because codegen didn't support union types (T52919652).
- When support landed, D63681874 upgraded to `ColorSchemeName = 'light' | 'dark' | 'unspecified'` — a type-level cleanup that inadvertently widened return types to include `'unspecified'`, a value native never returns. This caused `$FlowFixMe` suppressions across downstream callers.
- D80705652 later aligned the `.d.ts` and fixed a bug where `setColorScheme('unspecified')` threw an incorrect invariant.
Changelog:
[General][Breaking] - `useColorScheme()` no longer returns `'unspecified'` (this was always the case, but is a breaking type change)
Reviewed By: cipolleschi
Differential Revision: D102527387
Summary:
Removes `'unspecified'` from the return type of `Appearance.getColorScheme()` and `useColorScheme()`, splitting the setter input into a separate `ColorSchemeOverride` type. This resolves a longstanding misalignment between what native returns and what the types promise.
**Motivation**
`'unspecified'` is only meaningful as an input to `setColorScheme()` — neither iOS nor Android ever returns it from `getColorScheme()`. When `setColorScheme('unspecified')` is called, the JS layer re-queries the native module and caches the resolved system value.
After this change:
- `Appearance.getColorScheme()` returns `'light' | 'dark'` (no longer `'unspecified'`)
- `Appearance.setColorScheme()` receives `'light' | 'dark' | 'unspecified'`
Paired with docs updates:
- facebook/react-native-website#5060
- facebook/react-native-website#5069
**History of this API**
- The TurboModule spec originally typed these methods as plain `string` because codegen didn't support union types (T52919652).
- When support landed, D63681874 upgraded to `ColorSchemeName = 'light' | 'dark' | 'unspecified'` — a type-level cleanup that inadvertently widened return types to include `'unspecified'`, a value native never returns. This caused `$FlowFixMe` suppressions across downstream callers.
- D80705652 later aligned the `.d.ts` and fixed a bug where `setColorScheme('unspecified')` threw an incorrect invariant.
Changelog:
[General][Breaking] - `useColorScheme()` no longer returns `'unspecified'` (this was always the case, but is a breaking type change)
Reviewed By: cipolleschi
Differential Revision: D102527387
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Removes
'unspecified'from the return type ofAppearance.getColorScheme()anduseColorScheme(), splitting the setter input into a separateColorSchemeOverridetype. This resolves a longstanding misalignment between what native returns and what the types promise.Motivation
'unspecified'is only meaningful as an input tosetColorScheme()— neither iOS nor Android ever returns it fromgetColorScheme(). WhensetColorScheme('unspecified')is called, the JS layer re-queries the native module and caches the resolved system value.After this change:
Appearance.getColorScheme()returns'light' | 'dark'(no longer'unspecified')Appearance.setColorScheme()receives'light' | 'dark' | 'unspecified'Paired with docs updates:
History of this API
stringbecause codegen didn't support union types (T52919652).ColorSchemeName = 'light' | 'dark' | 'unspecified'— a type-level cleanup that inadvertently widened return types to include'unspecified', a value native never returns. This caused$FlowFixMesuppressions across downstream callers..d.tsand fixed a bug wheresetColorScheme('unspecified')threw an incorrect invariant.Changelog:
[General][Breaking] -
useColorScheme()no longer returns'unspecified'(this was always the case, but is a breaking type change)Reviewed By: cipolleschi
Differential Revision: D102527387