Closed zhaoyao91 closed 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.
@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.
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?
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?
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.
If there's more to it please reopen it. Thank you!
say, if I create a class on the constructor of a component, how to revoke this class when destroying the component?