Next.js: Enable multiple instances of Next on one page

[soofka]

Feature request

Is your feature request related to a problem? Please describe.

Currently it is not possible to display two separate Next.js-based applications on the same page, if one attemps to do so, he gets an error. It is caused by the fact that Next.js-based application mounts on DOM elements with fixed IDs: __next and __NEXT_DATA__.

Describe the solution you'd like

We'd like IDs of elements on which Next.js-based application mounts to be parameterized, possibly provided in application build script. We've forked Next.js and implemented this change in our fork: https://github.com/Raudos/next.js/commit/a4da2b6c2dbbec2f3f5d5b3e1c9cf24273d79dde. This PoC was created during workshop at meet.js in Katowice, Poland on 29.09.2019 (https://summit.meetjs.pl/2019/zeit-workshop).

Describe alternatives you've considered

We've considered not having multiple separate Next.js-based applications on one page, but we're building our application in microfrontend architecture, hence in many cases we want to avoid having whole page as a single application.

Additional context

More information on our approach to microfrontend architecture can be found here: https://medium.com/stepstone-tech/microfrontends-extending-service-oriented-architecture-to-frontend-development-part-1-120b71c87b68 (we've not considered Next.js at the time of writing this article).

[timneutkens]

I don't understand why you'd want to do this. It causes a large number of problems for virtually no gain. You'd increase JS size with every app added and Next.js is built to control the whole page by design. This way we can do optimizations etc.

[gom3s]

Hi @timneutkens, the issue is, that if you already have micro-frontend architecture, you are currently limited to just one Next.js fragment (endpoint).
The micro-frontends architecture is a trade off, but for large organisation - it seems to be worth it. Benefits of micro-frontends include:

• Incremental upgrades
• Simple, decoupled codebases
• Independent deployment
• Autonomous teams
  There is great article by Cam Jackson explaining this better than I can.

[timneutkens]

If you're trying to implement exactly what is outlined in the initial issue you're building a massively slow application. Instead you can do something like https://github.com/zeit/next.js#multi-zones

This is how many (very large) organizations have implemented separation of deployment, upgrades, codebases etc.

[soofka]

Thanks a lot for your feedback @timneutkens! For both quick response and clear communication :-).

Our idea that we could put multiple Next.js apps on one page was reinforced by @ijjk during workshops I've mentioned in initial message, and this feature request was created based on his advice. Apparently we must have misunderstood each other! :-)

To summarize, am I right saying that approach we've proposed here is not compatible with current Next.js design and there are no plans to support this kind of feature? If so, please kindly disregard this feature request :-)

We'll look into multi zones and see how can we use them. Thanks for advice!

[timneutkens]

Hey @soofka, basically the main problem is that Next.js has to control the whole page in order to optimize the most out of it. Having multiple Next.js apps running on the same page would cause issues for this reason, especially as the project would grow it would become slower and slower. Hence why multi zones would be the way to go here.

[mihaerzen]

@timneutkens You are correct and the whole idea of micro frontends doesn't interfere with what you wrote regarding the optimisations. You are also assuming Next.js will be used in a certain way, however, a simple configuration option to change hardcoded ids and some other variables (basically what @soofka did in https://github.com/Raudos/next.js/commit/a4da2b6c2dbbec2f3f5d5b3e1c9cf24273d79dde) would allow developers to be more flexible.

Another reason for this kind of feature would be security. Sometimes you would want to hide what technology you are using and one of the measures when using the Next.js would be to change the mentioned fixed ids.

I've also seen other issues opened where users wanted to change the __next id to have a nicer css structure.

Personally would love to see a feature where you could specify the currently fixed ids. I'm more than happy to make a PR but only if I can get some sort of confirmation it won't get rejected afterwards.

p.s.: Thanks for all the hard work, really appreciate it!

[schmod]

Personally, my use-case is as simple as wanting to have a consistent header/footer on all of my sites (without having to recompile/re-deploy each of them).

I agree that more complicated use-cases are problematic, but there are also likely quite a few simpler use-cases that are pain points for a lot of folks.

[timneutkens]

however, a simple configuration option to change hardcoded ids and some other variables (basically what @soofka did in Raudos@a4da2b6) would allow developers to be more flexible.

This is incorrect, as said you'd still be building an extremely slow application with tons of duplication, it'd be a false sense of "flexible".

I've also seen other issues opened where users wanted to change the __next id to have a nicer css structure.

And those were not landed either, as there is no reason to change that in particular, especially with regards to CSS you can just select #__next for example.

Going to close this as it's unlikely we'll introduce this in the near future. We might investigate it under enterprise support. Feel free to email [email protected] about it.