4 ms·
I'd propose the following distinction, especially for React users: If your components will only ever be used by you or a small, internal team of programmers, t
by iandanforth 11y ago
I'd propose the following distinction, especially for React users:
If your components will only ever be used by you or a small, internal team of programmers, then inline styles can work.
If, however, your components are meant to be re-usable, public and accessible then CSS is still a must.
To pick on one project react-datagrid is a super useful, public component for displaying data, but they use inline styles, which makes integrating the component into any other design a nightmare. You have to fork their codebase to update a style because you can't over-ride it and there's no way they'd pull in a PR for your preferred style.
- muzmath 11y agoHow about if you design the styles so you can pass in a styles object via the parent element, and the style-elemnt gets merged in to overwrite the defaults? is there a reason this wouldn't work?
- iandanforth 11y agoThey tried that in react-datagrid, but they forgot to expose a bunch. It's easy to use inline styles and hard to go back and add the layers of exposed properties you need to make sure they are accessible.
- namuol 11y agoYes! Why aren't more people making this observation? One of the huge selling-points of React is the modularity of components, and yet styles frequently ruin that modularity. Anyway, I got so frustrated with the state of things that I created a library aiming to provide a solid interface for third-party component authors: https://github.com/namuol/react-declarative-styles https://github.com/namuol/react-declarative-styles (Still very early stages/not published on NPM) And yeah, I stress the same points you just made about the problems of using inline styles with third-party components: https://github.com/namuol/react-declarative-styles/blob/master/CSS_OR_INLINE.md#conclusions https://github.com/namuol/react-declarative-styles/blob/mast...