[scroll area] Forced reflows / Layout trashing

[oliviertassinari]

Reproducible example

Since #2778, when there are multiple ScrollArea on screen (e.g., our docs pages), we force React to update the DOM to render each, so it means that each component needs to read the DOM. We have a cascade of forced reflows:

https://693ae9e6a41ca30008471aaf--base-ui.netlify.app/react/components/select, from the before example of #3531

Current behavior

Expected behavior

Intuitively, I wouldn't expect flushSync to be needed in this context; it feels like this fix hides a deeper problem.

Base UI version

v1.0.0

Which browser are you using?

Chrome

[github-actions]

This fix will be available in the next npm release of Base UI.

In the meantime, you can try it out on our Canary release channel:

npm i https://pkg.pr.new/@base-ui/react@3536

[oliviertassinari]

@atomiks Nice clean-up of the logic in #3536 👍. Love to see us fixing stuff at the root.

As for #3534, as far as I can read the performance timeline on https://deploy-preview-3536--base-ui.netlify.app/react/components/select. We, in a loop, read, then write, then read, then write in the DOM. Proof:

9 times. So the PR doesn't solve the issue. It's coherent with what the code has. We read the DOM with stuff like viewportRef.current, and write with stuff like thumbYEl.style.transform.

Considering that under a light page, each read/write cycle in the DOM takes 1ms, a page with 10 instances of the scroll view component would slow the page rendering by 20ms. It's not that bad. But a human eye can perceive motion changes starting from 5ms differences. Looking at the alternatives:

• https://github.com/KingSora/OverlayScrollbars: they gave up When the body page length is too large, the console will issue a performance warning KingSora/OverlayScrollbars#703, while it's really bad on https://kingsora.github.io/OverlayScrollbars/, 100ms spent in layout trashing 🫠
• https://github.com/sakhnyuk/rc-scrollbars: not even aware
• https://www.reshaped.so/docs/utilities/scroll-area solves the problem by relying on React DOM write batching: https://github.com/reshaped-ui/reshaped/blob/796d1a46bb221dfc25eb0c1a1e45e85cebd6b7db/packages/reshaped/src/components/ScrollArea/ScrollArea.tsx#L138
• radix: same issue as us.

We could ignore this for now, wait for someone to have a compelling reason to need to fix this. https://github.com/radix-ui/primitives/issues?q=is%3Aissue%20state%3Aopen%20reflow has no issues about this, so maybe it's OK, as is.

To fix, I see two options:

1. We implement our own batching logic to read and write.
2. We rely on React write batching; we rerender right after mount to set the right values, but maybe it's slower than the browser-style pipeline.