Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

useOpaqueIdentifier and multiple React cases #18565

Closed
theKashey opened this issue Apr 9, 2020 · 2 comments
Closed

useOpaqueIdentifier and multiple React cases #18565

theKashey opened this issue Apr 9, 2020 · 2 comments

Comments

@theKashey
Copy link
Contributor

React version: experimental

This is a theoretical issue, and is not proven to be a real issue. Written after #17322

Steps To Reproduce

  1. Use multiple independent version of react
  2. Get a clash of ids

The current behavior

Every React instance is generating ids based on a single counter, which increments every time new id is generated.
That counter is stored inside react-dom and it's lifetime is bound to React instance lifetime causing:

  • undefined behaviour in tests/mocks, which might clear nodejs module cache by different reasons.
  • unpredictable results with lambda as a backend, as long as many different renderers are working in a parallel, and their lifetime is limited.
  • potentially broken state when more than one lambda is used to generate server response (multiple roots during SSR to speedup/parallelise rendering)
  • guaranteed broken state on the client, with multiple react roots using different React instances, which could occur when the host application is not written in react, or when those "multiple" root as self-contained (aka widgets) and modules resolution is not hoisting a single React version to the top (for example parent application is just "old").

The expected behavior

Let's imagine a static site generator.

  • You run it once and got 1000 HTML files.
  • You run it twice, and all those 1000 files got updated.
  • 🙀, you haven't changed anything!

👉 So the expected behavior is to get the same result no matter on server up time. This means that counter should be "per-render", or "per-react-root".


Let's imagine there is a old legacy Java site, and we are adding two (non iframe based) widgets to it, both are self-contained (ie just "bundled"), and both are using the same React version.
Then they would generate the same ids in the same order.

👉 this is purely frontend issue, and both React instances, even if separated, are living in the same DOM/window. They should somehow talk to eachother, and probably prefix their ids with some uuids


Let's image the microfrontend, but old (or new, aka fragment cache) SSR-only application. For example I do have one very old, initially php-based application, where every "block" is generated by a subsequent network request. Nowadays some of those "blocks" are using React, just for a better SSR experience (because, well, I am not using php that much for last 10years).
👉 every time you render App it shall produce the same Ids, to mend static site generators, however, what if different apps could prefix their ids differently?


To be honest - there 3 points sounds like CAP theorem - you never gonna have all 3 at once.

@theKashey theKashey added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label Apr 9, 2020
@gaearon gaearon added Component: Server Rendering Type: Discussion and removed Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug labels Apr 9, 2020
@bvaughn
Copy link
Contributor

bvaughn commented Apr 16, 2020

Related: #18576

@gaearon
Copy link
Collaborator

gaearon commented Mar 30, 2022

hydrateRoot and renderToPipeableStream accept identifierPrefix which lets you have independent IDs if multiple Reacts have to be on the same page.

@gaearon gaearon closed this as completed Mar 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants