-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Platform specific colors via PlatformColor #126
Comments
@tom-un, might be able to fill in some more details. But for our macOS RN platform we extended the valid values for color. So you can specify either system colors, or be able to specify colors that change based on the native theme Something like: <View background={{dynamic:{light: 'red', dark:'pink'}}} /> I believe there was some plan to look at contributing that back for iOS too. |
thanks for starting the proposal!
from my reading of the docs, it seem like this changed and depending on how it's implemented, activities might not be recreated when the system theme changed. Because of that, I think a pattern similar to how we treat orientation makes more sense |
@acoates-ms will you describe that a bit more? That seems like a good solution for brownfield applications too where they need robust native themes. It's a solution that helps beyond just this light/dark mode use case and instead pushes themes into the native platform, which may or may not be desirable. @mmmulani that makes a lot of sense. It'd also give more flexibility for other platforms as well that might not recreate automatically. |
Also worth mentioning that we recently added an accessibility prop on View called |
@TheSavior I experimented with that some -- it works relatively well, but there are definitely places where people are going to need to manually handle this. In our apps that's the case, and when I tried some other popular RN apps it was mixed as well. I'll definitely submit that PR -- wasn't familiar with that. I don't think it directly addresses this discussion though. |
On macOS Mojave, things works best when using semantic colors: one sets colors on NSView using semantic colors such as [NSColor windowBackgroundColor] etc. Every view in the hierarchy has an 'effectiveAppearance' property that can change when the system changes from light to dark mode or vis versa. When the layers backing the views re-render the conversion of the NSColor to a CGColor is automatically aware of the effectiveAppearance and you'll get a different RGB value in the CGColor. iOS doesn't have appearance changes yet, but its a good bet it will in the same way as Mojave soon -- looking forward to WWDC for more info there. I prototyped a couple approaches when making our macOS react-native Mojave theme aware. The first approach was to make a JS Api similar to Platform. I called it SemanticColor.js and it behaved similar to Platform: on JS load it used NativeModule constants to initialize a map of semantic color names to RGB string. Then the JS subscribed to an 'theme has changed' event that would be send a new map -- similar to how Platform caches the screen orientation and then gets updated orientation values from an event. The problem with this solution was that the JS App itself also had to subscribe to the "theme has changed" event and then had to do a hard re-render of the components so that StyleSheets would be reevaluated because the various StyleSheets now contains RGB values fetched from the SematnicColors.js dictionary. Doing such a hard re-render would invariably reset some App state that the App developer didn't bother persisting. A simple example RNTester which does persist which test panel the user has navigated to, and the filter string, but does't persist the scroll position in the list. So with every theme change the list pops back to the top. Also, the time to re-render the whole App can be too slow so that instead of the RN app participating in the nice Mojave theme change animation it would just pop to the new theme a second or two after the rest of the desktop. So the second approach, which is what is in our macos fork, is the extension to the color type itself, so that a color can be expressed as the current RGB string values or a JSON object like { semantic: 'windowBackground' }. The RCTConvert object turns such JSON objects into a true NSColor semantic color. mac and iOS also have the concept of Asset colors: app defined named colors that have a light and dark variant. I made a RCTDynamic color (a sublcass of NSColor) that works like an Asset color. The JS can express the tuple { dynamic: { light: 'rgb', dark:'rgb' } } and RCTConvert turns it into a RCTDynamic. The semantic names I came up with for { semantic: 'name' } map 1:1 to the mac NSColor semantic names. And hopefully those same names will be used in a future iOS. But obviously don't map to other platform 1:1. Perhaps we could define a platform agnostic semantic namespace that would serve apple/android/windows. |
This should continue the conversation: https://developer.apple.com/videos/play/wwdc2019/214/ |
Hey! Poking this thread a bit with some interest on the React Native for Windows side. I'm a PM on that team (RN for Windows) and we're looking to enable support for the light and dark themes that we have. With the introduction of Dark theme in iOS 13 - as @DimitarNestorov mentioned, and the Dark theme mode in Android it's probably time we had something like this for all systems. We have an internal proposal to support both themes, as they're integral to developing on Windows, but I'd like to append that here to get the opinions of the community before we submit a larger spec PR to the main React Native github. Here's a look at part of the spec I've written that I would like to introduce to React Native core. I actually work closely with @acoates-ms, so a lot of this may look familiar to his suggested approach above as well as similar to what @tom-un was looking at. I would love feedback 😄 Responding to Light/Dark Themes in React NativeSummaryWith the introduction of React Native for Windows, there needs to be a way to utilize/work with the Light and Dark themes at the JavaScript layer.
MotivationAny React Native developer that wishes to follow the guidance of a Windows app will need to have access to the theme brushes, or at the very least a way to know when the system theme has changed. There are several reasons why this is important to the React Native developer when they run their app on Windows:
ScopeThere are two core aspects that need to be available to the app developer in order to have a Windows Light/Dark theme sensitive app:
Basic examplesExample 1 : Set up and behaviors on theme changedIn this example, we'll look at three things:
Setting up your app to be sensitive to theme changesFirst import the Platform API into your React Native app. import { AppThemeState } from 'react-native'; Create a local variable to use in style conditionals or to reference elsewhere easily. class MyAppClass extends Component {
state = {
appThemeState: AppThemeState.currentTheme,
};
...
} Switching styles based on the app's themeIf the app author wants to switch the style of their component manually based on the system's theme (Dark or Light), they can do so with CSS style conditionals. <TextInput
style={[styles.inputStyle, this.state.appThemeState.currentTheme == 'dark' ? styles.darkInput : styles.lightInput]}
</TextInput> Handling a theme changed eventIn this case an app author would like to do something or preform some behavior when the app's theme has changed.
componentDidMount() {
AppThemeState.currentTheme.addListener('themechanged', this.onAppThemeChanged);
}
onAppThemeChanged = (event) => {
/*Logic on theme changed goes here*/
this.setState({appThemeState: AppThemeState.currentTheme});
} API Design OverviewA look at the APIs for the features and scope described above. AppThemeState.currentThemeThe specifics of the event or API being fired/used.
App theme enumThe
|
I thought of a bit different approach on the API though. I was thinking about developer experience and the thought of event emitters just scared me. Let's start with the basics: I borrowed the idea from Apple about dynamic values (UIColor with a callback, 20:50 of the talk). However React Native doesn't use objects or functions for values, so I thought of dynamic stylesheets. Basically our good old StyleSheet with support for dynamic values. const dynamicStyles = new DynamicStyleSheet({
container: {
backgroundColor: new DynamicValue('white', 'black'),
flex: 1
},
text: {
color: new DynamicValue('black', 'white'),
textAlign: 'center'
}
})
function Component() {
const styles = useDynamicStyleSheet(dynamicStyles)
return (
<View style={styles.container}>
<Text style={styles.text}>My text</Text>
</View>
)
} And here's the benefit to such an approach: let's say that this component is being reused inside a view that has to be only in dark mode. No problem, useDynamicStyleSheet will use context underneath so all you'll have to do is provide the theme you want that component to be in: function MyScreen() {
return (
<>
<DarkModeProvider mode="dark">
<Component />{/* will be rendered using dark theme */}
</DarkModeProvider>
<DarkModeProvider mode="light">
<Component />{/* will be rendered using light theme */}
</DarkModeProvider>
<Component />{/* will be rendered using current theme */}
</>
)
}
export class DynamicValue<T> {
constructor(public readonly light: T, public readonly dark: T) { }
}
const logoUri = new DynamicValue(require('./light.png'), require('./dark.png'))
function Logo() {
const source = useDynamicValue(logoUri)
return <Image source={source} />
} function Input() {
const placeholderColor = useDynamicValue('black', 'white')
return <TextInput placeholderTextColor={placeholderColor} />
} I got excited last week about dark mode on iOS and I already implemented those ideas: https://github.com/codemotionapps/react-native-dark-mode These hooks currently work because of a native module, which publishes changes to the theme using event emitter. And if you want to subscribe to that event emitter all you have to do is import it (hopefully you don't). To detect the theme change in iOS I decided to use method swizzling on My proposal: A similar high level API, with an alternative for class components. And a better solution for the iOS implementation, something that would require a tiny change to RN core to keep it lean, have it as a module like AsyncStorage and the others. |
@DimitarNestorov : that's a really intriguing proposal. The DynamicValues and DynamicStyleSheet approach has advantages over an event emitter approach. (I prototyped an event emitter approach for macOS dark mode and noted the downsides in my post above). I also feel the semantic color values of the platform are also important. They're important for continuity across the device, but really important for continuity in apps that are hybrids contain a mix of pure native views and react-native views. I finally made the time to extend the work I did in macOS react-native dark mode to iOS. As expected, the iOS mechanism revealed at WWDC is very similar to macOS. Here's what the prototype looks like: The branch with the code changes is here: microsoft/react-native-macos@master...tom-un:tomun/ios-darkmode My proposed change is a change to core: its a change to the ColorType itself to support a platform specific named color. Every platform has some notion of named colors, and adding them to each platform's implementation I believe is a win for the react-native platform. Dimitar's proposal is also really interesting in that it provides a generic dynamic type that is applicable for things beyond just colors, like dynamic image sets. |
👋🏼 I'm tracking issues related to iOS 13 and Android Q, and supporting Dark themes is my current focus. First I'd like to thank everyone in the thread for the thoughtful discussion and for collecting all the relevant information. I've been having discussions around Dark Mode with other members of the core team, and I want to make sure folks here are aware of our current thinking. @tom-un's proposal is compelling. By exposing the underlying This does bring some questions:
It seems like providing a How do folks feel about moving forward with a React Hook approach first, and revisit adaptive color support later? |
Why not design something based on the web api that isn't limited to one theme? |
If you plan on using context we can then do a dynamic style sheet library similar to my approach in https://github.com/react-native-community |
@DimitarNestorov At this point, I am not considering extending Nicolas brings up a good point. I had not fully considered the current approach to theme preferences in web yet. Would folks prefer something closer to |
A generic theme is definitely better. Dark-mode only will probably look short-sighted in a few years if there are other themes (not necessarily just color-oriented either e.g. 2d theme vs 3d themes). |
A concern that I have about using the semantic and dynamic platform colors is that this won't translate well over to web because no equivalent exists there. This might be a good option to support but we should be careful about adding it, and we'll need to consider things like how well we can normalize the names across platforms and so on.
|
It might be that we (or RNWindows) can surface whether Windows High Contrast mode is active via this hook too (and hopefully MS will eventually expose it to web apps via the preferred-theme media query) |
I've landed on the following approach:
What do folks think we should do with |
FWIW, the web platform has specced several independent queries related to this feature (roughly "user preferences"), including:
The first 2 are supported by modern browsers, the last 2 are not yet supported. In the future, there are likely to be queries related to ambient light level, font-size, audio, and whether the UA/OS is forcing colors (another part of OS-level high contrast modes). This is in addition to all the existing queries related to viewport dimensions, aspect ratio, orientation, resolution, etc. Each of these queries can be passed to |
I think it's preferred to leave it as-is for now and discuss different pieces like this in separate RFCs. It's pretty easy to make a wrapper to account for theme in userspace: https://github.com/react-navigation/native/blob/f9334201893f93c81d6900811b481cee3818c748/src/Themed.js#L18-L37. |
@hramos @necolas - do you think type UserPreferencesConfig = {
colorScheme: 'light' | 'dark' | 'no-preference';
reducedMotion: 'reduce' | 'no-preference';
contrast: 'low' | 'high' | 'no-preference';
reducedTransparency: 'reduce' | 'no-preference';
};
type UserPreferencesListener = (config: UserPreferencesConfig) => void;
type UserPreferencesEvents = 'change';
const get = () => UserPreferencesConfig;
const addChangeListener = (listener: UserPreferencesListener) => EventSubscription;
// or if you prefer this style
const addListener = (event: UserPreferencesEvent, listener: UserPreferencesListener) => EventSubscription; for this first pass we could just expose the edit: perhaps |
I'm afraid Edit: Naming nits aside, I agree with breaking this down into individual preferences (e.g. |
@hramos - good timing, I just edited my comment with the same note re: |
This is what I've landed on, roughly:
|
@yungsters : Thanks! Regarding you're feedback on the following: cross-platform and cross colors:The idea of RNTesterApp.ios.js const styles = StyleSheet.create({
headerContainer: {
backgroundColor: PlatformColor('tertiarySystemBackgroundColor'),
... RNTesterApp.macos.js const styles = StyleSheet.create({
headerContainer: {
backgroundColor: PlatformColor('windowBackgroundColor'),
... etc. RNTesterBlock.js const styles = StyleSheet.create({
container: {
...Platform.select({
ios: {
backgroundColor: PlatformColor('tertiarySystemBackgroundColor'),
},
macos: {
backgroundColor: PlatformColor('windowBackgroundColor'),
},
default: {
backgroundColor: '#ffffff',
},
}), Another approach that we use in several projects, and is pretty much the same concept as CSS Variables, is to define color constants files for each platform: const Background = PlatformColor('tertiarySystemBackgroundColor');
... MyAppColors.macos.js const Background = PlatformColor('windowBackgroundColor');
... etc. Platform Options'options' is perhaps too vague of a term. What it really is is a To answer your specific question about the @brentvatne : to reply to your comment: As @acoates-ms replied, it would be problematic to have a function that returns an RGB "flattened" color because system colors on many platforms such as ios, mac, and windows are not limited to simple RGB values: they can be complex materials such as patterns, gradients and other complex rendering compositing constructs. For some apple UIColor/NSColor's it is possible to "extract" an RGB approximation, but for others such as patterns it is impossible. On iOS, all the current iOS 13 semantic colors can in fact be approximated to an RGB. On macOS, there a few colors that are patterns that cannot even be approximated to RGB. And on both platforms, any RGB value would be just an approximation. On macOS, for example, 'windowBackgroundColor' is at casual observation just a light grey or dark grey depending on the theme. But in fact 'windowBackgroundColor' actually renders by sampling the colors of the desktop behind the window and tinting the color. Apple calls this "Desktop Tinting". More importantly, any future semantic colors on any platform could do anything so I would discourage the idea of ever exposing a function to return the RGB of a NativeColorValue. The concept of a platform color is by its definition not cross platform. A developer that wants a simple RGB palette this is uniform across all platforms may still do so in react-native. But for complex brownfield apps that need to seamlessly integrate react native views into existing pure native views, it's critical that all the elements in the hierarchy use platform color constructs. |
thanks for the clarification @tom-un! |
Hi @TheSavior , responding to your feedback: The Flow type checking was working in my prototype branches -- but you got my doubting. So as a test I added a hypothetical Android NativeColorValue. You were right: it didn't validate unless In the Microsoft fork of react-native, I discovered that we actually have other hidden Flow validation problems. As in the facebook repo we have Regarding your suggestion to have a native module to register native colors: I believe that would work -- I'll try prototyping it. Also, regarding the opaque type: I actually wasn't aware of this Flow concept. I will also prototype this suggestion and investigate if there is a TypeScript equivalent. |
@TheSavior : I updated the @acoates-ms and I had some concerns about potential performance issues with requiring apps to call a native What if there were simply platform specific factory methods for each platform in addition to @yungsters : I implemented your idea of a fallback array of colors. The definition of export const PlatformColor = (...names: Array<string>): ColorValue => {
...
} I updated the I pushed these changes to facebook/react-native@master...tom-un:fb-platformcolor |
Concerning cross-platform, pretty sure we will find lot's of people doing very similar things as const styles = StyleSheet.create({
container: {
...Platform.select({
ios: {
backgroundColor: PlatformColor('tertiarySystemBackgroundColor'),
},
macos: {
backgroundColor: PlatformColor('windowBackgroundColor'),
},
default: {
backgroundColor: '#ffffff',
},
}), Shouldn't RN offers a common denominator for some colors? I am myself in the process of doing this & pretty sure tons of people will be interested by this as we are all going to have background, main text, lights text colors etc |
I'm thinking I'd expect that to be a potentially separate solution that would be built on top of this. I think we have to support the API you mention with |
Can be built on top for sure. |
Regarding Android colors: I have very limited experience developing on the Android platform, but I jumped in anyway and prototyped an Android From my research, Android color resources in XML are expressed as strings: These formats seem to be reasonable values for the Conveniently, almost all the color props in the react-native implementation are annotated I updated The prototype is not handling the I would love to hear from Android experts their opinions on this solution. |
Thanks to the guidance of @tom-un , color references that include
|
Hey everyone, is there any update for this proposal? Will it come soon? |
@ezranbayantemur Looks like the PR facebook/react-native#27908 is being finalized and will be merged soon :) |
@Dexwell Sounds amazing ! |
…Color PR. (#28040) Summary: The [PlatformColor PR](#27908) is currently open to implement the [PlatformColor proposal](react-native-community/discussions-and-proposals#126). When that PR was imported into Facebooks internal builds it was found that the change to the `processColor()` function to return an opaque type or `number` instead of just `number` breaks internal components. This PR is a simplification of the PlatformColor PR only changing the return type of `processColor()` from `?number` to `?number | NativeColorType` where `NativeColorType` is just an empty but opaque type. This will allow changes to be made to these internal components but with less risk than the larger PR. ## Changelog [General] [Changed] - Add NativeColorType opaque type to normalizeColor() ahead of PlatformColor PR Pull Request resolved: #28040 Test Plan: Flow checks, Jest test, iOS unit tests, iOS integration tests, and manual testing performed on RNTester for iOS and Android. Differential Revision: D19860205 Pulled By: TheSavior fbshipit-source-id: 799662c6621d3974158b375ccccfa136982c43b4
Summary: This Pull Request implements the PlatformColor proposal discussed at react-native-community/discussions-and-proposals#126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester. Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window. The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects. `PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version. The function returns a `ColorValue`. On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`. On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML: XML Resource: `@ [<package_name>:]<resource_type>/<resource_name>` Style reference from current theme: `?[<package_name>:][<resource_type>/]<resource_name>` For example: - `?android:colorError` - `?android:attr/colorError` - `?attr/colorPrimary` - `?colorPrimaryDark` - `android:color/holo_purple` - `color/catalyst_redbox_background` On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes. Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>` Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method. ## Changelog [General] [Added] - Added PlatformColor implementations for iOS and Android Pull Request resolved: #27908 Test Plan: The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests. <img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png"> In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes: react-native for macOS branch: microsoft/react-native-macos@master...tom-un:tomun/platformcolors react-native for Windows branch: microsoft/react-native-windows@master...tom-un:tomun/platformcolors iOS |Light|Dark| |{F229354502}|{F229354515}| Android |Light|Dark| |{F230114392}|{F230114490}| {F230122700} Reviewed By: hramos Differential Revision: D19837753 Pulled By: TheSavior fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
…Color PR. (facebook#28040) Summary: The [PlatformColor PR](facebook#27908) is currently open to implement the [PlatformColor proposal](react-native-community/discussions-and-proposals#126). When that PR was imported into Facebooks internal builds it was found that the change to the `processColor()` function to return an opaque type or `number` instead of just `number` breaks internal components. This PR is a simplification of the PlatformColor PR only changing the return type of `processColor()` from `?number` to `?number | NativeColorType` where `NativeColorType` is just an empty but opaque type. This will allow changes to be made to these internal components but with less risk than the larger PR. ## Changelog [General] [Changed] - Add NativeColorType opaque type to normalizeColor() ahead of PlatformColor PR Pull Request resolved: facebook#28040 Test Plan: Flow checks, Jest test, iOS unit tests, iOS integration tests, and manual testing performed on RNTester for iOS and Android. Differential Revision: D19860205 Pulled By: TheSavior fbshipit-source-id: 799662c6621d3974158b375ccccfa136982c43b4
Summary: This Pull Request implements the PlatformColor proposal discussed at react-native-community/discussions-and-proposals#126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester. Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window. The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects. `PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version. The function returns a `ColorValue`. On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`. On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML: XML Resource: `@ [<package_name>:]<resource_type>/<resource_name>` Style reference from current theme: `?[<package_name>:][<resource_type>/]<resource_name>` For example: - `?android:colorError` - `?android:attr/colorError` - `?attr/colorPrimary` - `?colorPrimaryDark` - `android:color/holo_purple` - `color/catalyst_redbox_background` On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes. Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>` Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method. ## Changelog [General] [Added] - Added PlatformColor implementations for iOS and Android Pull Request resolved: facebook#27908 Test Plan: The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests. <img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png"> In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes: react-native for macOS branch: microsoft/react-native-macos@master...tom-un:tomun/platformcolors react-native for Windows branch: microsoft/react-native-windows@master...tom-un:tomun/platformcolors iOS |Light|Dark| |{F229354502}|{F229354515}| Android |Light|Dark| |{F230114392}|{F230114490}| {F230122700} Reviewed By: hramos Differential Revision: D19837753 Pulled By: TheSavior fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Does Android have colors that can be used with |
@zachgibson yes. You need to use theme attributes when referencing colors, for example |
I'm going to close this issue as the feature listed in the OP has landed and is now a part of React Native |
Seems that android react to mode changes only on reload, could you please check here what if I'm doing anything wrong ? facebook/react-native#32823 cc @tom-un |
seems that wix is working around this issue somehow, pc-template.mp4 |
also platform Colors does not seem to be working with borders on android tested on latest RN |
The Each What could be the issue? |
Edit: A more general proposal has been posted by @tom-un to support generic platform defined colors. Jump to that proposal. That proposal now supersedes the one in this top post.
Original Proposal
### Introduction
Android Q introduced a Dark theme across the system and applications. From their presentation, "Users will expect apps to have a dark theme". The way we do styling on RN today isn't directly compatible with their solution, but it's close.
The Core of It
I opened facebook/react-native#24790 with a proposed solution, but it admittedly had some issues:
Platform
, but it's more prone to change than the rest of those valuesDiscussion Points
Platform
? While it is a device setting, it's not quite in the same class as things likeVersion
.The text was updated successfully, but these errors were encountered: