Hacker News new | comments | show | ask | jobs | submit login

> Is styled-components better? I don't know yet, but so far I like it.

Consider these two scenarios:

a) Someone using your component must also understand your component's full stylesheet and must determine (through analysis or through your naming conventions) what she can safely change about your component's styling, vs which parts are likely to be changed by you (or completely refactored) in future versions.

b) Someone using your component gets an API for the things they should be able to change about your component. The rest of your component can be updated (and its implementation changed) as you see fit, and as long as the consumer has followed your public API, the new version will work.

I think that with scenario A you lose most of the benefit of components, since you expose (and force the user to understand) some of the implementation details that she should not modify.

Whereas with scenario B you get the benefit of having an encapsulated unit of code with a clear interface, while being free to modify its implementation as long as the public interface continues to work as expected.




An additional bad part of A, if you look at many bootstrap sites, themes and components that aren't built from source projects, is you also wind up with a LOT of bloat for style definitions that aren't even used. Winding up with kludge on top of kludge, in a large project, where eventually you have to deeply namespace everything to overcome some abstract rule for a part of the app/site you can't even find if it's used anymore.


There's tooling for that: https://github.com/simlrh/dead-css-loader

CSS modules are about 95% of the way to making this a solved problem.

Obviously this relies on imported components implementing CSS modules, but for a greenfield project this kind of thing works remarkably well.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: