Eventually support/use multiple React roots? about next.js HOT 12 CLOSED

@mmmeff a simple solution would be something like @dlindenkreuz suggested with Next allowing the dev to customize the app component which remains the same instance across client-side navigations. The conceptual model would be similar to your example where you create an "app shell".

from next.js.

Can you recommend me some articles to read up on that?

@dlindenkreuz check out: https://react-server.io

which should either be left up to the user or which has to be done by Next.js in an elegant, unobtrusive way.

Yeah, I'm thinking about it in terms of a Next implementation detail that the dev isn't concerned with.

from next.js.

Guys, with v1.2.x now we can share modules between pages. Now if a module used by all of the pages, it'll be move into the commons.js.

Eventually, we'll add support tuning options.

About the multiple react-roots, it's kind a questionable. Not sure we'll do it by default.
But you will be able to do that once we support this: #251.

I am closing this issue because I think we are clear on this topic. But feel free to reopen if you are looking for something different.

from next.js.

Using more than one React root is a rather unusual solution to this problem. Did you test if Next.js routing actually prevents reconciliation and thus, common elements like a shared <Navigation> are forcibly re-rendered?

from next.js.

In the issue #88, I suggest having an editable top-level App container where these common elements could reside. This could be a solution to your problem as well.

from next.js.

@dlindenkreuz I think that's the simplest solution here and fits this projects' philosophy best.

from next.js.

@dlindenkreuz Currently, Next eschews React's reconciler during client-side navigation and re-renders the entire dev-prodvided tree. This is because the of how React's reconciler works w.r.t. a component's type and key and Next's approach to "page" components.

It would be possible to use the same top-level page component by always exporting it from all your ./pages/*.js files, but if you want to implement getInitialProps(), you'd need to re-implement routing so you can run the right logic for the current router/url since getInitialProps() would be a static method shared for all pages.

Another reason I'm bringing up multiple React roots is to support HTTP response streaming that doesn't have to wait for the entire tree to render. I think there's a reasonable middle ground where the dev can provide the app shell (as you're suggesting), and Next does some intelligent rendering (possibly using multiple roots) to allow server response streaming and client-side component instance reuse.

from next.js.

Here's a link to an example I built that shows how you can re-use a single definition of your layout across all your pages without repeating any code. https://github.com/mmmeff/nextjs-page-template-example

from next.js.

@mmmeff I'm not talking about reuse at the coding level, I'm talking about component instance reuse at the React reconciler level during runtime in the browser. What you have will still be entirely torn down between client-side navigations because index.js and about.js export different React component types.

https://facebook.github.io/react/docs/reconciliation.html#the-diffing-algorithm

from next.js.

@ericf Well aware (and listed it as a caveat in my readme). Any ideas on potential workarounds though?

from next.js.

Another reason I'm bringing up multiple React roots is to support HTTP response streaming that doesn't have to wait for the entire tree to render

@ericf Wow, I honestly never thought this was possible. Can you recommend me some articles to read up on that?

A customizable top-level App component would probably solve this in the simple way the project is aiming at. Having multiple roots sounds like a low-level conceptual decision (even though I'm not yet enlightened what this is all about 😀) which should either be left up to the user or which has to be done by Next.js in an elegant, unobtrusive way.

from next.js.

+1 for having a way for the user to maintain state across pages (not necessarily with multiple roots though), for shared navigation elements with their CSS transitions, and also for Redux and GraphQL clients such as Apollo. Maintaining the state in window (as currently suggested for Redux in the Wiki and explored for Apollo in #106) feels more complex than it might need to be?

from next.js.