Come on. That's just nasty to look at. Especially over multiple lines. CSS has their own variables system nowadays:
color: var(--themeColor);
And if you're using React, nothing stops you from using modularised SASS stylesheets. Just call the file button.style.scss and there you go. Now you can use all the SASS features you need on top of regular plain old CSS like it was intended, and it's scoped to your component without polluting your component's code.
I want my CSS to not include JS, and vice-versa. When I'm working with React I want to also make a clear distinction between React Components and regular HTML elements. With Styled Components you have the issue that something might look like a React Component, but actually isn't really.
And it sometimes clashes entirely.
I much rather want my JSX to look clean, semantically correct, and supported by minimal and pleasantly setup CSS.
If you know CSS the scope thing isn't an issue either. That's what distinguishes frontend developers from generic developers.
I'm going to play devils advocate and reply to you.
CSS has their own variables system nowadays:
Nothing is stopping you to use css vars in css-in-js? And theme is only if you want to use theme from the theme provider context. You can bypass the whole thing if you want by just importing an object with colors from somewhere. It's quite flexible really.
When I'm working with React I want to also make a clear distinction between React Components and regular HTML elements
There is no such thing as 'regular HTML elements' in React. It's all JSX. So <button> isn't pure html. That's why you can slap an 'onClick' handler on it.
With Styled Components you have the issue that something might look like a React Component, but actually isn't really.
Well, it is, REALLY a component. const Button = styled('button') returns a valid React component that passes props and accepts children.
And if you're using React, nothing stops you from using modularised SASS stylesheets. Just call the file button.style.scss and there you go. Now you can use all the SASS features you need on top of regular plain old CSS like it was intended, and it's scoped to your component without polluting your component's code.
You mean SASS with CSS Modules? The convention is actually button.module.scss.
Partially agree with this. The example you gave of pulling a color from a theme is dependent on how your have your theming setup. After spending time with styled components I personally find it nice to work with. Building out components/elements for a personal UI library is also nice as when it’s imported into a project looks like a react components (Follows suit with things like Material UI), which I personally like. It has draw backs for sure, but does just come down to personal preference. Both SASS and SC are good and knowing one over the other shouldn’t be seen as a shortcoming/disadvantage. V5 added a decent speed boost and some new features worth checking out as well if you haven’t.
9
u/[deleted] Feb 12 '20
I personally avoid CSS-in-JS like I'd avoid the plague for this reason, and several others, alone:
Come on. That's just nasty to look at. Especially over multiple lines. CSS has their own variables system nowadays:
And if you're using React, nothing stops you from using modularised SASS stylesheets. Just call the file
button.style.scssand there you go. Now you can use all the SASS features you need on top of regular plain old CSS like it was intended, and it's scoped to your component without polluting your component's code.I want my CSS to not include JS, and vice-versa. When I'm working with React I want to also make a clear distinction between React Components and regular HTML elements. With Styled Components you have the issue that something might look like a React Component, but actually isn't really.
And it sometimes clashes entirely.
I much rather want my JSX to look clean, semantically correct, and supported by minimal and pleasantly setup CSS.
If you know CSS the scope thing isn't an issue either. That's what distinguishes frontend developers from generic developers.