Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
gitbreaker222 opened this issue Aug 27, 2019 · 2 comments
Open

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

gitbreaker222 opened this issue Aug 27, 2019 · 2 comments

Comments

@gitbreaker222
Copy link

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
Copy link
Owner

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants