-
Notifications
You must be signed in to change notification settings - Fork 49.1k
Description
React version: experimental
This is a theoretical issue, and is not proven to be a real issue. Written after #17322
Steps To Reproduce
- Use multiple independent version of react
- Get a clash of
id
s
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 withlambda
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 uuid
s
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.