3 ms·

Theming is on of the big reasons we saw the need to make styled-components[0] (new lib to style React apps and component libraries) I'm one of the maintainers

by mxstbr 10y ago

Theming is on of the big reasons we saw the need to make styled-components[0] (new lib to style React apps and component libraries) I'm one of the maintainers of ElementalUI, and Glen Maddern, the styled-components co-creator, one of the creators of CSS Modules. One of the biggest downsides of CSS Modules (and, by extension, every other styles in JavaScript library right now) is that theming is simply impossible. Building third-party component libraries is hard enough, but providing an easy-to-theme API wasn't a solved problem in the React world. Nobody has done it properly, and there is no agreed-upon way of doing this! styled-components has built-in theming support[1] to solve this exact problem. (note: this is CSS-in-JS, not inline styles[2], so overriding is easy as pie too[3]) We're rebuilding ElementalUI with it right now and the next versions of react-toolbox and Belle will be built with it as well. We also have ReactNative support, which nobody else has done before. Just because you're writing a universal React app with a third-party component library shouldn't mean switching between three or four different APIs to style your app. With styled-components, you can just use styled-components no matter what you're styling! (If you're reading this, I'd love to have a chat with the Antd people about maybe moving to styled-components! You can reach me on Twitter at @mxstbr, just ping me there!) [0]: https://styled-components.com [1]: https://github.com/styled-components/styled-components#theming [2]: mxstbr.blog/2016/11/inline-styles-vs-css-in-js [3]: https://github.com/styled-components/styled-components#overriding-component-styles

Zalastax 10y ago
A big issue I see with CSS-in-JS at this moment is server-side-rendering and caching. You started working on a babel-transform for extracting static styles but seem to have changed your mind about actually extracting that to a css-file[1]. Requiring a JS-parser to apply the styles is the wrong approach but might be a stepping stone as it's probably an easier problem to solve. Separating JS and CSS should improve performance somewhat as the browsers can run the scripting and styling engine separately. In the end I'd like a transformation that creates one CSS-file per JS-file so that common chunks can be combined by webpack, gaining high cache hit percentage on sites that uses reloads. Transformations should also be applied to the JS so that SSR doesn't have to calculate styles each time. [1]: https://github.com/styled-components/styled-components/issues/59 https://github.com/styled-components/styled-components/issue...
- mxstbr 10y ago
  Would you mind chiming into that issue with what you imagine? I hadn't thought about caching yet, that's a good use-case for a separate CSS file! We also almost have a proper server-side rendering API[0], in case you haven't seen that PR before. Should be released very soon! [0]: https://github.com/styled-components/styled-components/pull/214 https://github.com/styled-components/styled-components/pull/...
  - Zalastax 10y ago
    I think the work you are doing right can be a stepping stone for something great! The advantages of more traditional methods of creating CSS are ahead-of-time-compilation, splitting/bundling (combine common chunks to achieve low cache invalidation, low transfer size, and high cache hits with few files), and no waiting for the JS-engine to parse and convert your internal data structure. SPA-SSR is in general a lot more CPU-heavy than the more traditional approach of instantiating templates. We need to find ways of minimising the redundant calculations performed by the server to regain the performance we lost in the transition from templates to SPA-SSR. A source code transformation that extracts CSS and removes static JS is one such step. The SSR API is a good start but completely trashes cache + creates a large .html each time you reload. The .html returned can most often not be cached so we should strive to minimise its size. The problem of caching/minimising server load is not the easiest to solve but we should be long on our way if we can analyse/signal what parts are static and which are dynamic.
just-boris 10y ago
Hello! I've been using Antd components for the last year in some my project. All components are also available here[0] as single modules for better reusability and customization. Currently, I have solved all my theming goals with Plain CSS. For each component, that I'd like to customize I created a wrapper import Slider from 'rc-slider'; function StyledSlider(props) { return <Slider className="my-slider" {...props} /> } Then in CSS .my-slider .rc-slider-track { background: #FFDF66; } (This is a very simplified example, just shows the way). I have read about styled-components, but I don't understand how it would help me with theming. I don't think that rewriting every component from LESS to styled-components to make possible to use ThemeProvider will be an option because it doesn't give you any benefits comparing with customization guide[1], that also gives you good enough way to override defaults. [0]: https://github.com/react-component/ [1]: https://ant.design/docs/react/customize-theme
- mxstbr 10y ago
  We're currently writing some documentation specifically pertaining to theming third-party component libraries, which you can read the WIP of here: https://github.com/styled-components/styled-components-experimentation/blob/master/component-libraries/shared-component-libraries.md https://github.com/styled-components/styled-components-exper... The TL;DR is that this customization guide will suddenly become really easy. Antd can specify a default theme and users can override the parts of the default theme they want! All the user has to do is pass a single prop to the ThemeProvier and override what they want: import { ThemeProvider } from 'antd'; <ThemeProvider theme={{ primaryColor: '#1DA57A' }}> <App /> </ThemeProvider> On top of that different parts of your app can have different themes. Making your sidebar dark but your main component light is not an issue – just wrap them in two ThemeProviders with different themes: <ThemeProvider theme={darkTheme}> <Sidebar /> </ThemeProvider> <ThemeProvider theme={lightTheme}> <Main /> </ThemeProvider> It's also all dynamic, meaning you can let the users of your app provide custom themes for your app and it'll automatically apply. Compare that with the current customization guide, not only do users have to use webpack, they also have to use specific plugins just to make customization of third-party components work! It's also all global, which means styling the sidebar dark and the main area light is impossible since it's all just Less variables applied at build time. This also makes it very hard to have user supplied themes. Does that make it clear enough how using styled-components would help with theming? :-)
mlsarecmg 10y ago
It is not a headache to retheme them. It is pretty easy, the easiest i've seen in a UI kit. You have style and classname overrides in place, scoped css classnames and LESS. If you use a CSS react-lib like React-CSJS, styling this is easy as pie.

by mxstbr 10y ago

Zalastax 10y ago

A big issue I see with CSS-in-JS at this moment is server-side-rendering and caching. You started working on a babel-transform for extracting static styles but seem to have changed your mind about actually extracting that to a css-file[1]. Requiring a JS-parser to apply the styles is the wrong approach but might be a stepping stone as it's probably an easier problem to solve. Separating JS and CSS should improve performance somewhat as the browsers can run the scripting and styling engine separately. In the end I'd like a transformation that creates one CSS-file per JS-file so that common chunks can be combined by webpack, gaining high cache hit percentage on sites that uses reloads. Transformations should also be applied to the JS so that SSR doesn't have to calculate styles each time. [1]: https://github.com/styled-components/styled-components/issues/59 https://github.com/styled-components/styled-components/issue...

mxstbr 10y ago
Would you mind chiming into that issue with what you imagine? I hadn't thought about caching yet, that's a good use-case for a separate CSS file! We also almost have a proper server-side rendering API[0], in case you haven't seen that PR before. Should be released very soon! [0]: https://github.com/styled-components/styled-components/pull/214 https://github.com/styled-components/styled-components/pull/...
- Zalastax 10y ago
  I think the work you are doing right can be a stepping stone for something great! The advantages of more traditional methods of creating CSS are ahead-of-time-compilation, splitting/bundling (combine common chunks to achieve low cache invalidation, low transfer size, and high cache hits with few files), and no waiting for the JS-engine to parse and convert your internal data structure. SPA-SSR is in general a lot more CPU-heavy than the more traditional approach of instantiating templates. We need to find ways of minimising the redundant calculations performed by the server to regain the performance we lost in the transition from templates to SPA-SSR. A source code transformation that extracts CSS and removes static JS is one such step. The SSR API is a good start but completely trashes cache + creates a large .html each time you reload. The .html returned can most often not be cached so we should strive to minimise its size. The problem of caching/minimising server load is not the easiest to solve but we should be long on our way if we can analyse/signal what parts are static and which are dynamic.

just-boris 10y ago

Hello! I've been using Antd components for the last year in some my project. All components are also available here[0] as single modules for better reusability and customization. Currently, I have solved all my theming goals with Plain CSS. For each component, that I'd like to customize I created a wrapper import Slider from 'rc-slider'; function StyledSlider(props) { return <Slider className="my-slider" {...props} /> } Then in CSS .my-slider .rc-slider-track { background: #FFDF66; } (This is a very simplified example, just shows the way). I have read about styled-components, but I don't understand how it would help me with theming. I don't think that rewriting every component from LESS to styled-components to make possible to use ThemeProvider will be an option because it doesn't give you any benefits comparing with customization guide[1], that also gives you good enough way to override defaults. [0]: https://github.com/react-component/ [1]: https://ant.design/docs/react/customize-theme

mxstbr 10y ago
We're currently writing some documentation specifically pertaining to theming third-party component libraries, which you can read the WIP of here: https://github.com/styled-components/styled-components-experimentation/blob/master/component-libraries/shared-component-libraries.md https://github.com/styled-components/styled-components-exper... The TL;DR is that this customization guide will suddenly become really easy. Antd can specify a default theme and users can override the parts of the default theme they want! All the user has to do is pass a single prop to the ThemeProvier and override what they want: import { ThemeProvider } from 'antd'; <ThemeProvider theme={{ primaryColor: '#1DA57A' }}> <App /> </ThemeProvider> On top of that different parts of your app can have different themes. Making your sidebar dark but your main component light is not an issue – just wrap them in two ThemeProviders with different themes: <ThemeProvider theme={darkTheme}> <Sidebar /> </ThemeProvider> <ThemeProvider theme={lightTheme}> <Main /> </ThemeProvider> It's also all dynamic, meaning you can let the users of your app provide custom themes for your app and it'll automatically apply. Compare that with the current customization guide, not only do users have to use webpack, they also have to use specific plugins just to make customization of third-party components work! It's also all global, which means styling the sidebar dark and the main area light is impossible since it's all just Less variables applied at build time. This also makes it very hard to have user supplied themes. Does that make it clear enough how using styled-components would help with theming? :-)

mlsarecmg 10y ago

It is not a headache to retheme them. It is pretty easy, the easiest i've seen in a UI kit. You have style and classname overrides in place, scoped css classnames and LESS. If you use a CSS react-lib like React-CSJS, styling this is easy as pie.