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

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-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? :-)

The ability to apply different overrides for some branches in a component tree is powerful. Sure, I will come back to styled-components when I will get that issue.

Currently, I (as well as most users, I suppose) just need to apply some global color overrides to match with company's brand guidelines that I can solve it with old good plain CSS.

Also, for big projects, like Antd, transition to some other CSS-tooling almost impossible, because CSS/LESS code is spread across several repositories and will take a lot of efforts and time.

And finally, the current implementation is better because it doesn't mention styles in Javascript at all, so the library users are able to choose any way to style components without extra efforts from the side of library authors.

You can choose to style styled components any way you want too! You can pass in class names, inline styles, whatever you want just works. No need to be aware of styled-components from the user side at all.

Imagine Button being a styled component, all of the usual methods work perfectly fine:

    import Button from 'antd';

    <Button className="my-global-classname" />

    <Button style={{ color: 'red' }} />

You say "just" apply some global color overrides, but to "just" apply some global color overrides you need to use webpack (using another bundler? Sorry, antd is not for you) and use atool-build or have to configure webpack to work the way they need it to.

Or you create a custom less file, but that means you'll load all the styling for all components even though you really only wanted to use e.g. the Button.

That's not really "just" overriding a global color, is it? ;-)

I'm not saying this is a trivial change at all by the way, I understand the cost of it since I'm doing it for ElementalUI. I don't know if the antd maitainers will consider it worth it, that's another discussion.

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/issue...

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/...

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.

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.