Open Harjot1Singh opened 4 years ago
Theme constants can be done as https://www.reactnative.guide/8-styling/8.0-intro.html
Did we also discuss theming being done on the component level?
At most we probably have to think about providing two "themes": The mobile app theme and the wireless display theme
One consideration I'd like to make is that nothing should affect our css. So hopefully no conflicting css rules or overridden rules like we have on desktop with material ui. The look of an app is core to the user experience and if we're aiming for a higher UX in mobile we should take a bigger step in controlling how we make the app look.
We should make sure we use colors as we intend them to be used. Blue for interaction items, soft green for info items, plain white/black for consumption / non-interactivity, etc. (Examples, not actual rules to use).
Here is an example of simply "powering up" the css capabilities of stylesheet without introducing it's own css (not sure if react-theme-provider does the same, would need to look into that): https://styled-components.com/
On the thought of theme constant: https://thoughtbot.com/blog/structure-for-styling-in-react-native
Here is an example of simply "powering up" the css capabilities of stylesheet without introducing it's own css (not sure if react-theme-provider does the same, would need to look into that): styled-components.com
I didn't quite understand this part of the comment, but styled-components and react-theme-provider do similar things, except that the latter provides an alternative syntax to achieve those capabilities.
https://github.com/shopify/restyle
is quite promising
UI libraries help a team get up and going fast. However they almost always end up causing us more trouble when refining / unifying our overall look/design.
Consider the theme provider we're looking at here. We already know what our constants colors are (that's not hard to do ourselves) and then for us to control where they are applied, and how, fits directly into our atomic components. So the component could have their colors pulled from a central lib theme file.
Mayhaps we should consider what aspect we are missing or we find hard to implement first? So we know what this issue is fixing
This library assumes that the UI is built upon a design system that (at the very least) defines a set of colors and spacing constants that lays as a foundation. While the library acknowledges that there can be exceptions to the system by allowing any style to be overridden, it keeps the developer most productive when one-off values are kept to a minimum.
I'd very much prefer to not re-implement the basics from scratch :) have done so already with the Typography component. It provides many OOTB, simple, unstyled layout-level components to build our own set without having to reinvent the wheel with handling spacing consistently and so forth. I was planning to add a few components it already has!
Choose theming solution and source all theming constants from one place, instead of defining them inline.
Something like https://www.npmjs.com/package/@callstack/react-theme-provider + wrapper hook to produce similar solution to MUI?