[WIP] Initial support for React fiber.

[arunoda]

Fixes #1098

We are not going to merge this soon unless React 16 ships before 3.0 release.
Otherwise, we need to look at a way to detect React 16 and support React patching if that's React 15.

[timneutkens]

Cool!

[stipsan]

Any chance this can be released on its own tag?

For now I've forked your branch and published it here to allow using React Fiber on a Next.js app I'm working on that uses the new react-dom/node-stream api.
I prefer not to fork and publish on npm as it's a bit noisy. When a fork is no longer needed you can't "unpublish" it from npm 😞

[arunoda]

@stipsan that's something we can do just after we release 3.0.
Using node-stream will be challenging as we need to update next/head and styled-jsx accordingly.

[stipsan]

Alright.
It is indeed challenging if the goal is to replace the SSR that next.js is doing for free with streaming. I'm not even sure if doing something like that makes sense. My use case is to stream a component directly to svg using my own route handler.
I don't have a lot of data yet on how using node-stream rendering performs in the real world yet, but my impression that it's primary use case is to keep memory usage low (by sending the string in chunks instead of the full string in one big push) turns out to be true. So far I've seen that it has slower total loadtime than using ReactDOMServer.

For my use case though it's a good tradeoff as I want to use in-memory cache for base64 encoded avatar uris (SVGs that are rendered in an <img> tag do not support loading remote files, only base64 uris).
Because of the base64 uri strings the resulting svg strings can be pretty huge, easily over 1MB. node-stream increases the amount of SVGs that can be rendered before hitting the RAM limit of the node 😄

I don't think it makes sense to use node-stream in use cases where you're not pushing a lot of data to the client. Which is most use cases, right?

[arunoda]

I don't think it makes sense to use node-stream in use cases where you're not pushing a lot of data to the client. Which is most use cases, right?

That's what we think right now. Streams doesn't add much in performance wise for Next.js.
But end of the day, this is something we need to consider.

[frol]

@stipsan @arunoda You are talking about streaming VS full-render performance from the unit of work perspective, but if you consider the performance from the user perspective you will notice that streaming can outperform full-render significantly due to the lower time to first byte (TTFB): https://www.youtube.com/watch?v=UhdGiVy3_Nk

[stipsan]

@frol thanks for sharing that video. It appears streams is the next performance frontier 😄

[msand]

@arunoda @rauchg Would it be possible to get this under a v3.1.0 beta, fiber or some similar tag?

[msand]

@arunoda @timneutkens
Is this supposed to work / be possible to use as a dependency already?
If I install arunodas fork commit hash using npm / yarn then I'm unable to start next.
If I install the latest version of next normally, and apply this or my own patch manually then it works fine.

[rawrmaan]

Fiber is now in RC and I'm having to maintain two branches (one with next and react 15, one with next disabled and react 16). Would be great to get a timeline in this, and I'd be happy to help in any way I can!

[Faradey27]

@arunoda react 16 is released, do you plan to merge?

[kjs3]

Continuing this work here: #2996

[timneutkens]

Tracking it here #2996