5 ms·

These components look and work great, but unfortunately are a real headache to retheme unless you want to pull in a sass/less toolchain in addition to what you'

by secoif 10y ago

These components look and work great, but unfortunately are a real headache to retheme unless you want to pull in a sass/less toolchain in addition to what you're currently using. This is a pain in the ass if you already have your theme variables set up in one compiles-to-CSS language. There is a standard for CSS variables and a very functional subset of their functionality can be compiled for older browsers at build time: http://cssnext.io http://cssnext.io, yet as far as I can tell, all of these component frameworks impose some other nonstandard compiles-to-CSS language or one of many possible APIs for writing inline styles. Inline styles seem to be a trend at the moment but I can only assume the people driving this movement haven't had the experience of working with 3rd party components (which you may or may not have the source for) and needing to alter something the designers didn't expose and simply having no simple options because the damn inline style can't be overridden even by !important. Now you've got to fork whole the f'ing component, possibly multiple, each of which potentially coming with yet another different compiles-to-CSS toolchain all because you wanted to add a single line of CSS. Admittedly, antd doesn't use inline styles si the above doesn't apply here, but having to maintain a custom builder for antd in order to change some fonts and a few colors was a frustrating experience. Not sure what a good solution is until CSS variables get more browser adoption, but it'd be great if we could collectively start standardizing on standards.

Lazare 10y ago
I agreed that it's been an unsolved problem, but I've been looking at 'styled-components' and I think it may be the answer. At least on paper, it solved the issues you raise. Time will tell I suppose.
Illniyar 10y ago
SCSS (and to a lesser degree LESS) are basically industry standard now, if you are using react, you are almost certainly using one of the two preprocessors. I don't think your complaint is relevant here, especially since you provide no solution. It bothers me that this reply is at the top of the comments.
- prashnts 10y ago
  The argument about inline styles is valid, in my opinion. I've had to fork and keep updating from upstream several react components for the exact same reason.
  - Illniyar 10y ago
    But it's not relevant to the article, since as they don't use inline styles.
- griffinmichl 10y ago
  I don't really see much of a need for preprocessors w/ css modules, post css, css in js, etc. It seems like preprocessors are becoming less popular, not more.
  - Keats 10y ago
    Looks like their (at least node-sass) popularity is growing: https://npm-stat.com/charts.html?package=node-sass&from=2015-11-30&to=2016-11-26 https://npm-stat.com/charts.html?package=node-sass&from=2015... I use libsass and postcss combined and pretty happy about it.
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...
mstijak 10y ago
Theming is a difficult problem. Each component has a couple of visual properties which may depend on the state (hover, focus, error, internal variable). Having a separate variable for each visual property would be a nightmare. I'm currently working on themes for a similar framework. It's still in early stage but you can see it here: http://cx.codaxy.com/v/master/themes/ http://cx.codaxy.com/v/master/themes/
- crudbug 10y ago
  Today, I was thinking about this problem. You can separate component Style into - BASE + States classes. classnames[0] can used to use multiple classes, the classes can be activated using component state. This provides a viable solution for Structure & Style. [0] https://github.com/JedWatson/classnames https://github.com/JedWatson/classnames
  - mxstbr 10y ago
    This is useful for structuring components internally, but sadly doesn't help solve the theming issue at all :-( What you want from theming is a global skin. You want users of your component library to be able to say "I want all of my buttons to be red" without having to wrap the component or pass a prop to every component. (simplified example) Doing so just with class names is very very hard. It's what we've done for ElementalUI (together with Less), but it just doesn't work – it's a pita for users!
  - mstijak 10y ago
    This exact approach is used for Cx components.
sidi 10y ago
I fail to understand this criticism. React Components expose a class hierarchy which can be namespaced well by their designers (if Antd isn't already doing this). Extending / theming with your specific CSS pre-processor is then pretty straightforward.
- secoif 10y ago
  Doing it this way requires overriding every single built-in rule that uses the property you're trying to override… including states like :hover, :before, :disabled, :disabled and :hover, etc which can be easy to miss. I've had some success with simple find & replace preprocessor but this gets complicated if the CSS uses colour manipulation functions e.g. color: color(var(--color-base) tint(50%)), then you're basically going to be re-implementing their whole stylesheet again. Also, good luck making sure everything still works if and when the components are updated. Ideally, you alter theme variables in one place, rather than finding and overriding them everywhere they're applied.
deleted 10y ago
[deleted]

by secoif 10y ago

Lazare 10y ago

I agreed that it's been an unsolved problem, but I've been looking at 'styled-components' and I think it may be the answer. At least on paper, it solved the issues you raise. Time will tell I suppose.

Illniyar 10y ago

SCSS (and to a lesser degree LESS) are basically industry standard now, if you are using react, you are almost certainly using one of the two preprocessors. I don't think your complaint is relevant here, especially since you provide no solution. It bothers me that this reply is at the top of the comments.

prashnts 10y ago
The argument about inline styles is valid, in my opinion. I've had to fork and keep updating from upstream several react components for the exact same reason.
- Illniyar 10y ago
  But it's not relevant to the article, since as they don't use inline styles.
griffinmichl 10y ago
I don't really see much of a need for preprocessors w/ css modules, post css, css in js, etc. It seems like preprocessors are becoming less popular, not more.
- Keats 10y ago
  Looks like their (at least node-sass) popularity is growing: https://npm-stat.com/charts.html?package=node-sass&from=2015-11-30&to=2016-11-26 https://npm-stat.com/charts.html?package=node-sass&from=2015... I use libsass and postcss combined and pretty happy about it.

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

mstijak 10y ago

Theming is a difficult problem. Each component has a couple of visual properties which may depend on the state (hover, focus, error, internal variable). Having a separate variable for each visual property would be a nightmare. I'm currently working on themes for a similar framework. It's still in early stage but you can see it here: http://cx.codaxy.com/v/master/themes/ http://cx.codaxy.com/v/master/themes/

crudbug 10y ago
Today, I was thinking about this problem. You can separate component Style into - BASE + States classes. classnames[0] can used to use multiple classes, the classes can be activated using component state. This provides a viable solution for Structure & Style. [0] https://github.com/JedWatson/classnames https://github.com/JedWatson/classnames
- mxstbr 10y ago
  This is useful for structuring components internally, but sadly doesn't help solve the theming issue at all :-( What you want from theming is a global skin. You want users of your component library to be able to say "I want all of my buttons to be red" without having to wrap the component or pass a prop to every component. (simplified example) Doing so just with class names is very very hard. It's what we've done for ElementalUI (together with Less), but it just doesn't work – it's a pita for users!
- mstijak 10y ago
  This exact approach is used for Cx components.

sidi 10y ago

I fail to understand this criticism. React Components expose a class hierarchy which can be namespaced well by their designers (if Antd isn't already doing this). Extending / theming with your specific CSS pre-processor is then pretty straightforward.

secoif 10y ago
Doing it this way requires overriding every single built-in rule that uses the property you're trying to override… including states like :hover, :before, :disabled, :disabled and :hover, etc which can be easy to miss. I've had some success with simple find & replace preprocessor but this gets complicated if the CSS uses colour manipulation functions e.g. color: color(var(--color-base) tint(50%)), then you're basically going to be re-implementing their whole stylesheet again. Also, good luck making sure everything still works if and when the components are updated. Ideally, you alter theme variables in one place, rather than finding and overriding them everywhere they're applied.

deleted 10y ago

[deleted]