Open gitbreaker222 opened 5 years ago
Are there any arguments agains JS-Class-name instead global state (assuming global state can be used for really everything)?
In a design system I've made recenty we have this for hiding stuff:
.js-enabled .js-hidden { @include moj-hidden(); }
.hidden { @include moj-hidden(); }
Both are global, but the first is for js components so that if js isn't on, the content is displayed.
Does that help?
Thanks for your reply :) I think this goes in the right direction, but maybe needs more background information (why/how show js-components for cases, where js is disabled?)
Maybe it is more clear, if we could stick to the collapser example from the javascript chapter
I think I can be more precise now after thinking deeper. Can we change this part?
The trade-off is that this list could grow quickly (or use a mixin). And every time we add behavior, we need to update the CSS. A small change, but a change nonetheless. In this case we might consider a
global stateJS-module-name class.
The code example would then be:
.Collapser-isHidden {
display: none;
}
... because we can then write CSS for all Collapsers, instead of putting weight on the "global-CSS-space". Let me know, if I can make a fork/pull-request for a specific diff.
When creating an element from a JS-Class, the current approach is to either use explicit module-class-names for every instance or absolute global state:
But we already have a (JS) class name "Collapser", so the first thing I would concider is using that instead of global state.
Question:
Are there any arguments agains JS-Class-name instead global state (assuming global state can be used for really everything)?
Proposal:
Replace
.globalState
with the js-class-name.Collapser
.The Javascript chapter sais:
In State: