[styles] Streaming server-side rendering

[pjuke]

#I'm looking into new features of React 0.16; in particular the new renderToNodeStream() method.
To be able to use that, one would need to provide all the necessary CSS before any other body markup to avoid the Flash Of Unstyled Content issue.

Is it possible with your JSS implementation to utilize this? I do not want to run the renderToString() method since it is slow. I'm looking for a solution where the markup could be parsed and the styles could be calculated pre-render, and then later render the final app with renderToNodeStream().

In pseudo code:

let markup = (<MyApplication />);
let css = calculateStyles(markup);

let stream = renderToNodeStream(<MyApplication css={css} />);
// stream.pipe etc. ...

I realize this might not be a material-ui specific issue, but rather related to JSS. But I'm curious if you already have thought about this for your framework.

[oliviertassinari]

@pjuke Yeah, this is something we could be doing with a React tree traversal algorithm, no need to render everything.
apollo and loadable-components are good examples of such React tree traversal. cc @kof

[kof]

If function values are used, props are needed. To get them a component needs to render. Once component is rendered - we have styles. Otherwise we would need to statically extract styles and disable function values.

[oliviertassinari]

@kof As far as I know, you have the properties when traversing a React tree.

[kof]

In that case it should work already.

[oliviertassinari]

@kof What do you mean? We can:

1. Travers the React tree in order to send the CSS first.
2. Get the class names and render the HTML with them.

[kof]

If by traversing you mean some sort of virtual rendering with reconciliation etc then we should already have an extractable css. Otherwise I need to see what that traversing does.

[oliviertassinari]

Here is a closer to reality implementation of @pjuke that we could use. The only part missing is traverseReact(). This function needs to take context into account. If we are lucky it has already been implemented by another library, e.g. react-apollo.

// Create a sheetsRegistry instance to collect the generated CSS
const sheetsRegistry = new SheetsRegistry();

// Create a sheetManager instance to collect the class names
const sheetManager = new Map();

// Let's traverse the React tree, without generating the HTML.
traverseReact(
  <JssProvider registry={sheetsRegistry}>
    <MuiThemeProvider sheetManager={sheetManager}>
      <MyApplication />
    </MuiThemeProvider>
  </JssProvider>
);

// Now, we can get the CSS and stream it to the client.
const css = sheetsRegistry.toString()

// Let's stream the HTML with the already generated class names
let stream = renderToNodeStream(
  <MuiThemeProvider sheetManager={sheetManager}>
    <MyApplication />
  </MuiThemeProvider>
);
// stream.pipe etc. ...

[kof]

I am wondering how traverseReact could be implemented. In order to know props you need to do most things renderToString() does anyways. So the question would be is there any perf benefit then.

[oliviertassinari]

@kof This is true. It needs to be benchmarked. Wait a second. I can do it right away on the project I'm working on. We use the same double pass rendering:

• graphql: 78ms
• react: 104ms

[kof]

Is it a benchmark or just one pass?

[oliviertassinari]

@kof this is a one pass on a large react tree with react@15. The results should be only relevant at the order of magnitude. It seems that traversing the React tree is what cost the most, it's not the HTML generation. I have heard that traversing the tree with react@16 is going to be faster.

I wish react was providing a Babel plugin like API to traverse the react tree! This way, we could be writing a custom plugin injecting small chunks of <styles /> as we traverse it.

So, I'm not sure we can push this issue forward.

[kof]

Even the order of magnitude can be wrong, you need to do many passes, because we have to see how v8 optimizes the code. From above numbers it is not worth streaming. Also don't forget that renderToNodeStream has also a cost.