5yrs in progress, it’s still not documented let alone fixed. I tried to look at the code, and they make giant PRs and are experimenting with priority queues and bitmasks, which seemed pretty off in the weeds to me.
Oh wow. I was always skeptical of "concurrent React" (the scheduler approach seemed insane to me), but this seems like such a basic issue, I'm surprised this ever shipped in any form.
IIRC it also only bales out during the DOM update phase; not during the calls to render() and then reconciliation(?). And if it bales out, it has to re-render everything again when it comes back to make sure the state is consistent(nothing has changed).
The exact details are fuzzy and that may be incorrect but the impression I came away with after reading an engineering post about the deets was that:
* The risk of thrashing seemed very high
* Debugging performance issues seemed like they were going to be a nightmare. Worse than right now. Worse than hook hell.
This line from the song Taro comes to mind: "Do not spray into eyes. I have sprayed you into my eyes.
> it also only bales out during the DOM update phase; not during the calls to render() and then reconciliation(?)
It's exactly the opposite.
React splits work into two parts: the "render phase", where it loops over components and asks them to describe the UI they want (returning JSX/elements); and the "commit phase", where it has determined the changes that _need_ to happen to the DOM.
The render phase is the part that can be split into many pieces. React can render a few components, see that 5ms has elapsed, and yield to the browser, then pick up where it left off and render a few more components. Or, it could render some components, pause, see a high-priority user event happen like typing into an input, and set aside the partially completed render pass to go re-render based on the input update. Then, after the input render is done, it can pick up where it left off with the other partial render, "rebase" it onto the current UI contents, and continue from there.
The commit phase is _always_ synchronous, start to end, and that's where the actual DOM updates are applied.
I think you're really misunderstanding how React works here.
There's no "thrashing" involved, in the sense of "make DOM update A, then need to make B that reads layout or does reflows right after".
- React does a render pass based on a state update, compares the element tree from this render vs the last render, and determines _all_ the necessary changes to make the DOM match the newly requested UI
- It then applies all those changes together, synchronously, in a generally efficient way (ie, modifying just specific attributes to existing DOM nodes if possible, vs recreating the DOM from scratch)
Which "performance issues" are you thinking of? Excess renders? DOM-specific reflows?
5yrs in progress, it’s still not documented let alone fixed. I tried to look at the code, and they make giant PRs and are experimenting with priority queues and bitmasks, which seemed pretty off in the weeds to me.