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
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.
React version: experimental
This is a theoretical issue, and is not proven to be a real issue. Written after #17322
Steps To Reproduce
idsThe current behavior
Every React instance is generating
idsbased on a single counter, which increments every time newidis generated.That
counteris stored insidereact-domand it's lifetime is bound to React instance lifetime causing:undefined behaviourin tests/mocks, which might clear nodejs module cache by different reasons.unpredictableresults withlambdaas a backend, as long as many different renderers are working in a parallel, and their lifetime is limited.brokenstate when more than one lambda is used to generate server response (multiple roots during SSR to speedup/parallelise rendering)brokenstate 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
countershould 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
idsin 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
idswith someuuidsLet'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
idsdifferently?To be honest - there 3 points sounds like CAP theorem - you never gonna have all 3 at once.