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

> are we now putting CSS in Javascript?

You are missing the point. Forget about client vs server, the idea is that in React you are working with components.

NOT putting component-local styles into the component's implementation is a mistake, and is equivalent to creating a cluttered global namespace with lots of stuff you shouldn't touch because the component expects it to work a certain way.

The right way is to let each component accept style props that the consumer is supposed to be able to change, but to keep the rest of the component's implementation private.

The idea of encapsulation is pretty basic in software engineering (functional and OOP) but for some reason people fail to realize that what makes components useful is that they create an encapsulation boundary that should reduce the cognitive load of using the component.




While I don't necessarily disagree with the benefits of encapsulation - not even native Android applications behave this way. What are your thoughts on that system, and is this simply because CSS is unreliable, or is your stance that this should always be the case?

What happens when I want to change every button from green to red? Does that happen in one place, or now many?


> What happens when I want to change every button from green to red

If you have a component that you maintain, it can depend on a global style definition that is itself a module. You can change the color of the button in that module.

If you have a component that you do not maintain, then you may look at the implementation of that component and change something that is currently "blue" to "red", but how do you know for sure that the maintainer of the component may not have something in mind or may choose to refactor that code or change the naming convention?

> is this simply because CSS is unreliable, or is your stance that this should always be the case?

My view applies to any approach to code that benefits from a distinction being drawn between a public and private interface. Generally, these are scenarios where the person or team maintaining the component may be different from the person or team using the component as a part of other code. The public interface is meant to be stable and behaves like a contract between the author of the code and the person using it. Semantic versioning is about declaring that public interfaces are or are not stable from the previous version.

If we put our styling code (usual data literals of some sort) into the global scope, but we plan to use conventions established by a component's author as our own convention, we risk the chance that the component's author may change something that we are depending on. The logical separation of styling code that is an implementation detail is what is important, not where in the codebase the declarations reside.

If a component author determines that the user of that component should be able to change style attributes a,b,c,d, and e, then those should be explicitly handled as part of the public API and the values passed to them (and whether they are required for proper functioning of the component) should be defined as well.

This is just good component hygeine. It helps insulate the consumer (person using the component in her own code) from having to read the component's source code to see how the implementation works simply to add styling information.


This is what Shadow DOM and CSS Custom Properties are for: Let the browser encapsulate styles, with both upper and lower bounds, and let specific values inherit through the encapsulation boundary.


Yes. These concepts are gradually starting to take hold in the web and traditional DOM world as well. Oh what a wonderful world it will be!




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

Search: