cristianbote / goober

🥜 goober, a less than 1KB 🎉 css-in-js alternative with a familiar API
https://goober.rocks
MIT License
3.14k stars 119 forks source link

how to remove added style? #206

Closed zhaoyao91 closed 3 years ago

zhaoyao91 commented 3 years ago

say, if I create a class on the constructor of a component, how to revoke this class when destroying the component?

cristianbote commented 3 years ago

Hey @zhaoyao91 thanks for opening this issue.

TL;DR; you can't.

The reason why you can't remove it from the stylesheet is the principle of how goober is handling writing to the stylesheet tag. Basically you can write to it, but can't remove it. That would be an extra operation needed.

But this begs the question of a use case. Why/when would you want to remove a class? If that class has been added, it goes without saying that it's used in the current rendering pass.

If I'm not mistaken, removing the class will also trigger a repaint. Which might affect the rendering performance.

Would love to learn more about the need to remove it.

zhaoyao91 commented 3 years ago

@cristianbote thanks for your reply. Nowadays micro frontend structure are popular. Under the situation, a page may have no knowledage of other page, and will only care about thing it owes. If some page left their styles, not only it wil blast the styles, but also the unintended styles may affect other pages.

cristianbote commented 3 years ago

Ah, ok. I think I understand your concern now.

I would make the case that the unintended styles side-effects it's unlikely, since goober or any other css-in-js library hashes the classes uniquely depending on the css rules it contains. So the clashing of the same styling by design it's impossible. This goes the same for the <style> tag. Each library uses/defines it's own tag.

The only case where this could be a concern in the case of microfrontend's approach, is if one of the library used will blast the goober's style tag, which is defined as <style id="goober"> </style>. Have you run into issues like this ones?

zhaoyao91 commented 3 years ago

No, I didn't meet the issue yet, just have some worry about the general infinite-grow pattern without any mechanism to do cleanup. We have a microfrontend app which allow the user to browse tons of pages without refresh. While sub apps would take responsibility to release resources, they are hard to free the style.

Another concern is about dynamic css. I found if I change some width from 0px to 100px, there would be 100 rules added. If we have a highly dynamic design such as with some object motions, would it create and retain too many rules?

cristianbote commented 3 years ago

You are 100% correct. Having this code will generate 101 unique classes:

const Div = styled('div')`
  width: ${p => p.width}px;
`;

<Div width={0} />
<Div width={1} />
// ...
<Div width={100} />

I can completely see your worry. What I usually do, when dealing with such dynamism inside the styles, I apply the highly dynamic rules inline. Usually those are coming from js powered animations.

On the bright side though, the dynamic classes will be generated only once 😄 and reused afterwards.

cristianbote commented 3 years ago

If there's more to it please reopen it. Thank you!