adamsilver / maintainablecss.com

93 stars 9 forks source link

[question] 10. Javascript: Classname instead globalState #5

Open gitbreaker222 opened 5 years ago

gitbreaker222 commented 5 years ago

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:

var module1Collapser = new Collapser(element1, {
  cssHideClass: 'moduleA-isHidden'
});

var module2Collapser = new Collapser(element2, {
  cssHideClass: 'moduleB-isHidden'
});
.moduleA-isHidden,
.moduleB-isHidden {
  display: none;
}
.globalState-isHidden {
  display: none;
}

But we already have a (JS) class name "Collapser", so the first thing I would concider is using that instead of global state.

/* selecting every "Collapser" instance that is hidden*/
.Collapser-isHidden {
  display: none;
}

/* if a specific Collapser-instance should look differnt */
.collapserA-isHidden {
  display: block;
  height: 0;
}

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:

[…] the global class will be referenced from within […] However, this approach doesn't always make sense. We may have two different modules that behave the same, but look different, which is something we've discussed in State.

In State:

[…] whilst states might be common, associated styles might not. For example, an empty basket has a gray background, where as an empty search has an absolutely-positioned image.
What about reusing state? Sometimes, we may in fact want to reuse state across modules or components. For example, toggling an element's visibility. This is discussed in more detail in the chapter entitled Javascript.

adamsilver commented 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?

gitbreaker222 commented 5 years ago

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 state JS-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.