-
Notifications
You must be signed in to change notification settings - Fork 264
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
Instance-based API instead of global singleton #64
Comments
After we did an implementation example of Styletron with custom |
@rtsao would you like / have time to implement this? |
@giuseppeg Someone else can jump on this as it looks like I probably won't be able to get to this anytime soon. |
We are going to tackle this in #389 |
Is this something with any internal momentum? Or is it something that a community member will probably have to tackle? |
Because of vercel/styled-jsx#64 styled-jsx needs to be a peer dependency for all libraries, and pulled in once by the App, so the instance can be shared.
Because of vercel/styled-jsx#64 styled-jsx needs to be a peer dependency for all libraries, and pulled in once by the App, so the instance can be shared. Related to: dhis2/ui-core#204
@giuseppeg any update on this? I'm running into this issue and I'm trying to launch a UI kit with styled-jsx. |
I think it would be nice if styled-jsx had a non-singleton interface.
The main use case I've found where a global singleton is problematic is related to rendering within iframes. In short, styles from components rendered within a iframe get rendered outside the iframe, preventing the styles from reaching inside the iframe.
The common pattern to solve this is to rely on React context to share instances, which allow the instance to be overridden within an iframe by overriding context. Then styles from components within a given iframe will be rendered within the iframe using its own instance.
This is somewhat uncommon use case, but creating a singleton interface from an instance is straightforward whereas going the reverse direction is much more difficult. I think making separate packages for the core and singleton interface would not add too much additional complexity or maintenance effort. I'd be happy to work on a PR, otherwise feel free to close this issue.
The text was updated successfully, but these errors were encountered: