The React way of separating design concerns from logic is to build container components[1] that handle the logic and pass props down to simple components that just display the data they're given. I would expect designers to spend more time in presentational components and CSS modules[2] while developers would build container components. (I'm a one-man shop doing both.)
[1] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...
That's a bit of a stretch though, we've had good success with using normal CSS files, included in each component with webpack CSS-loader[1]. CSS is displayed in head as needed, but without an all-JS approach like this
I can then, inside my component...
require('./mycomponent-style.scss')
.... <div class="mycomponent">
with the mycomponent-style.scss @import "variables";
@import "mixins";
.mycomponent {
...
}
And have all of bootstrap's variables/mixins to work with... I can update variables for those bits of bootstrap I want changed, components also update based on those values. It actually works really well, and it's not hard to setup.I should really write a current article on using Bootstrap@4 from source... There's a little bit of boilerplate, but so worth it.
That said, I do appreciate the inline options, and feel that future React apps in particular should probably go in that direction. It really just depends on how you are working with.
I'm not just being silly either. Separation of technologies (e.g. HTML/CSS/JS) is just one of many ways of splitting things up. The component paradigm is essentially a fractal version of separating by feature. Ultimately it's an architectural choice and as such any best practices should be strictly scoped to the problems they're solving.
The reason why many of us in React-land are looking to bring everything related to a single component into one file, is maintainability and strict encapsulation. Some of this is to do with developer-experience (DX), i.e. adopt patterns that make our lives easier and ultimately minimise hard-to-fix bugs. But we're also trying to adopt patterns that benefit the user (i'll be the first to admit we're not there yet). To that end, a component architecture also makes it easier to let build tools automatically take care of the nasty problem of making sure users only download exactly what they need for what they've asked to do.
I never thought there was a separation between JS and CSS, that sounds a little outdated, to be honest. As a front-end developer, I would be expected to do JS and CSS.
It seems odd to only allow the "designer" to manipulate properties of elements and not the elements themselves. If they are allowed to modify DOM elements then in the React world, that is manipulating JS. For us the important separation is at the component level, which includes everything that component needs to render and function (HTML, CSS, JS).
We are not using React.
(Not agreeing with this BTW, but there is a subset of developers who seem to think this is just great.)
I personally like this way better, easier to find when need to fix something.