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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: css-in-js integration for styled-jsx and styled-components #14
Conversation
ui/RootStyleRegistry.client.tsx
Outdated
import { ServerStyleSheet, StyleSheetManager } from 'styled-components' | ||
import { useFlushEffects } from 'next/dist/client/components/hooks-client' | ||
|
||
export default function RootStyleRegistry({ children } : { children: JSX.Element }) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we build this into Next.js somehow? I would love to prevent the world where folks need this in userland.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is intended that to let users to create their own custom styles registry for any css-in-js, so that we can keep the bundle as minimal as possible on client side. Even styled-jsx we removed the built-in support for layouts. This approach was brought up by @sebmarkbage
What users need to do is:
- Wrap the content under a client component
- use
useFlushEffects
API in that client component to consume flushed style content for each streaming render
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part of this story is that we discourage using either of these approaches since this approach doesn't work well inside Server Components since you have to resend them, and the client runtime overhead is not worth it compared to .css
file generating solutions. If we were encouraging their usage then maybe the tradeoff of having them built-in would make more sense, but now it's a benefit that it's an opt-in to a solution we're not recommending.
This approach works well with existing mechanisms that these libraries use and it doesn't require useFlushEffects to be built-in to React.
That said, we might add something to React to make it easier to have this work out of the box. Not because we encourage it but because it's so heavily used for legacy purposes and it'll conflict with some other new features too. That would require heavy refactoring to these libraries anyway so it's not as useful in the short term anyway.
I will restyle them with tailwind later.
Changes
Preview