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

Prevent rehydration of existing styles #3128

Open
Dan-Trott opened this issue Nov 23, 2023 · 0 comments
Open

Prevent rehydration of existing styles #3128

Dan-Trott opened this issue Nov 23, 2023 · 0 comments

Comments

@Dan-Trott
Copy link

Dan-Trott commented Nov 23, 2023

The problem

We distribute a popup widget that uses emotion and our customers install it on their page via a remote script.

We have found that customers that use emotion on their page and install our widget may experience CSS issues due to the instance of emotion loaded by our widget causing their emotion styles to be rehydrated. Sometimes this process can result in the style tags being reordered, causing problems.

From what I can tell, this is because the customer is using the default cache key.

It seems that when emotion/react is loaded by our widget, the CacheProvider context is always created with the default key. As this happens during loading, it doesn't seem like we are able to avoid it. Even when we create our own cache with a custom key, this default cache is always created first.

? /* #__PURE__ */ createCache({ key: 'css' })

Proposed solution

It looks like it might be tricky to make the default cache key configurable so I wonder if we could instead prevent hydrated nodes from being rehydrated?

  • When a style node is first hydrated, we add a data-hydrated attribute to it.
  • When any new cache is loaded, it will ignore any style nodes with the data-hydrated attribute.

Do you see any problem with this? If not, we would be happy to contribute this change when we have the time.

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

No branches or pull requests

1 participant