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

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.




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

Search: