CSS-in-JS with Suspense SSR?

[devknoll]

Most CSS-in-JS libraries support SSR in a pretty similar way to styled-components:

const sheet = new ServerStyleSheet()
const html = renderToString(
  <StyleSheetManager sheet={sheet.instance}>
    <YourApp />
  </StyleSheetManager>
)
const styleTags = sheet.getStyleTags()
// Usually, we'd `renderToString` again with `<head>{styleTags}</head>`

That is, they rely on the React tree being rendered synchronously to accumulate all of the styles used, so that they can generate the final CSS for you to include in the document.

In #37 we can see that with the new SSR architecture, HTML is flushed to the browser incrementally as suspense boundaries are resolved on the server, not all at once at the very end. This seems to imply that compatible CSS-in-JS libraries can't rely on being able to put their styles in <head> or generating a single <style> and instead need to support this sort of incremental flushing too, right?

What should CSS-in-JS libraries that want to be compatible with the new Suspense SSR be doing instead? There was mention of built-in utilities to address issues like this so it would be interesting to hear if such a feature is in scope for the initial release of React 18 and if not, what libraries should do in the meantime.

[threepointone]

I'd previously (4 years ago, wow) written a transform that would intersperse <style> tags with react's streaming response, so I assume it would do something similar? https://github.com/threepointone/glamor-stream The problem with my implementation, is that once react would rehydrate it would have mismatched tags (which makes sense, since I'm adding tags outside of react's process.) so I had to have a step that would extract those tags out and put them into <head> before react's hydration would kick in.

(There's also separate conversation to be had with libraries that do "static extraction", and where/how <link> tags should be added and suspended)

(and yet another conversation, separate from SSR but still regarding concurrent mode, whether calling stylesheet.insertRule() like most css in js libs do, interferes with a subtree that's using concurrent features and react's scheduling work.)

Happy to make separate threads for these questions, but would love to hear what the react team is thinking about in general right now?

[kitten]

This could in theory even be done progressively. Say, a CSS-in-JS library is instantiated already. As long as the style tags have appropriate markers, a library could potentially use the MutationObserver API to rehydrate styles progressively.
I haven't really looked into the potential performance implications of this but twind does this to dynamically swap out Tailwind-like classes: https://github.com/tw-in-js/twind/blob/main/src/observe/index.ts

[Andarist]

so I had to have a step that would extract those tags out and put them into before react's hydration would kick in.

This is also what Emotion currently does. I'm not entirely sure though how safe it is - I mean, if the HTML is streamed then JS can be executed during that process as HTML should not block JS, right? So I think it is possible for our style-moving logic to be executed before the whole response gets streamed which effectively can leave style elements that arrive later untouched. And that can lead to a hydration mismatch. This, of course, will also be less than ideal in React 18 where the hydration ain't synchronous.

Streaming style elements within the body etc can still cause visual problems if selectors like :first-child are used. I wonder though when exactly the browser paints stuff and if there are guarantees around that - like, what kind of tasks are guaranteed to be executed before the user sees the next "chunk" of the streamed HTML.

whether calling stylesheet.insert rule() like most css in js libs do, interferes with a subtree that's using concurrent features and react's scheduling work.

I believe this is safe to do, at least for libraries like Emotion and Styled-Components. The worst-case scenario seems to be that some rules can get inserted without ever being actually rendered to the DOM (if the associated render won't ever get committed). I'm not aware of any CSS-in-JS libs that are not idempotent~ like that but maybe there are some? And even if there are no libs like this right now - should React take a stance about this and require idempotency in this area? Given that render purity is already a requirement it might be OK to make that a requirement as well. (I know that maybe idempotency ain't the most correct word to describe this trait but I've always thought about it that way and I struggle to find a better way for it right now).

---

A somewhat additional, interesting, topic is - how this could mix with Server Components which are rendered in a stateless manner, while most CSS-in-JS have a client-side state (css rules cache). Are Server Components expected to always "overrender" style elements just so they could be ditched by the client if they can already be found in the cache?