iamhosseindhv / notistack

Highly customizable notification snackbars (toasts) that can be stacked on top of each other
https://notistack.com
Other
3.89k stars 299 forks source link

Styles not applied when rendering in custom element with shadow dom #576

Open muxahuk opened 1 year ago

muxahuk commented 1 year ago

When using custom element, with shadow dom attached, to render react application - styles are not being applied and there is no posibility to tell notistack to render styles in different element.

Expected Behavior

I expect to be able to control where the style tag is rendered, in my case i want it to be rendered in the shadow dom of my custom element

Current Behavior

I cannot control where the style tag is being rendered and it is rendered always in the "head" of document.

Steps to Reproduce

Link: https://codesandbox.io/p/sandbox/mutable-thunder-t5h5r6?file=/src/main.tsx:17,11

  1. render app in custom component with shadow dom
  2. Add Notistack Provider
  3. add buttom to show snackbar
  4. click on the button

Context

We have application that is being served to clients as custom element that is being embedded on they websites. Not to interfier with client styles we are using shadow dom / mode to isolate styles so that their styles do not affect our widget and our styles do not affect they website. We encountered a problem when updated to v3.0.1 that we cannot configure anyhow "notistack" to "emit styles in our custom element shadow dom". We have emotion cache provider set up properly to emit styles in our shadow dom wich was applied to v2.0.8 of notistack i guess..

Your Environment

-

Tech Version
Notistack v3.0.1
React 18
Browser not relevant
PrimaMateria commented 1 year ago

Hi, coincidentally, I am currently dealing with the same problem as you. I have modified your sandbox code to manually inject the styles under the shadow root using goober's extractCss function. I am not sure if this is the most elegant solution, but it works.

https://codesandbox.io/p/sandbox/nifty-gwen-rtrrd5?file=%2Fsrc%2Fmain.tsx%3A7%2C29

muxahuk commented 1 year ago

Hi, coincidentally, I am currently dealing with the same problem as you. I have modified your sandbox code to manually inject the styles under the shadow root using goober's extractCss function. I am not sure if this is the most elegant solution, but it works.

https://codesandbox.io/p/sandbox/nifty-gwen-rtrrd5?file=%2Fsrc%2Fmain.tsx%3A7%2C29

thanks for your input, i was trying to do extractCss, but didn't figured out how that should work and what are the possible implications as this should be used for SSR, as i understood from they docs... Moreover i see that they still inject style tag into head, aldough it's empty and should not affect anything, i would steel want to avoid it. image

In they docs they mention that we can use target to pass container root where style tag will be rendered https://goober.js.org/api/targets but there's no way to control it through notistack. May be if we could pass styled and css variables directly into Provider that could solve this issue, but will leave solution up to developers, if they decide to fix this at all..

NicerDicerPro commented 1 month ago

Hi everybody,

i just stumbled upon this problem because im using notistack inside a shadowDom within an React application.

goober.extractCss() cleared the _goober style-tag outside the shadowDOM correctly, but always returned a empty string instead of the css for some reason. I couldn't figure out why.

I ended up kindof doing the same but without the extractCss method but doing it myself:

const gooberStyles = document.getElementById('_goober')?.textContent || '';

return (
  <>
    <ThemeProvider theme={themeContext.light ? customLightTheme : customDarkTheme}>
      <ScopedCssBaseline>
        <style id="_gooberCopy">{gooberStyles}</style>
        <SnackbarProvider>{children}</SnackbarProvider>
      </ScopedCssBaseline>
    </ThemeProvider>
  </>
);

It's not pretty but for now it seems to work. Maybe this helps someone who stumbled upon this bug too (as its still not fixed as of August 1st 2024).