You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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.
The text was updated successfully, but these errors were encountered:
React version: experimental
This is a theoretical issue, and is not proven to be a real issue. Written after #17322
Steps To Reproduce
id
sThe current behavior
Every React instance is generating
ids
based on a single counter, which increments every time newid
is generated.That
counter
is stored insidereact-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.broken
state when more than one lambda is used to generate server response (multiple roots during SSR to speedup/parallelise rendering)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.
👉 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 someuuid
sLet'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.
The text was updated successfully, but these errors were encountered: