[Cascade] Improve scroll sync implementation by eokoneyo · Pull Request #256511 · elastic/kibana

eokoneyo · 2026-03-06T16:58:09Z

Summary

This PR is part of the cascade performance improvement work(#255745), culled from #256037.

Refactors the ScrollSyncProvider to eliminate per-row scroll overhead by centralizing scroll coordination into a single capture-phase listener with an allocation-free hot path.

What changed

Single capture-phase scroll listener: Replaced N individual resize observers and onScroll React handlers (one per row) with a single native scroll listener attached at the provider's wrapper element using { capture: true, passive: true }. This bypasses React's synthetic event system entirely for programmatic scroll events and uses a scroll-leader pattern to prevent the O(N^2) feedback cascade where each scrollTo write re-triggers handlers on all other rows.
useSyncExternalStore for scroll state: Replaced per-row useState + onScroll with a centralized pub/sub store. The provider computes three boolean flags (isScrollable, canScrollLeft, canScrollRight) and only emits to subscribers when the booleans actually change — not on every pixel of scroll. Consumers call useSyncExternalStore(subscribe, getSnapshot) for batched, stable re-renders.
Cached layout dimensions: scrollWidth and clientWidth are cached in the provider and only refreshed via ResizeObserver or on hover. The scroll hot path never reads these layout-forcing properties from the DOM.
Zero-allocation scroll hot path: All intermediate objects are mutated in place to minimize GC pressure:
- Scroll state booleans are compared inline; a new snapshot object is only allocated when they change (~2-3 times per session, not per event).
- A single reusable ScrollToOptions ref is shared across all scrollTo calls instead of allocating { left, behavior: 'instant' } per container per event.
- cachedDimensions are updated via property assignment, not object replacement.
- for...of loops replace .forEach to avoid closure allocation.
- The scroll-leader timeout callback is hoisted to a stable useCallback ref.
Instant programmatic scrolling: All programmatic scrollTo calls use { behavior: 'instant' } to override the CSS scroll-behavior: smooth on scroll containers, ensuring synchronized rows update in the same frame as the leader. User-initiated smooth scroll (e.g. arrow button clicks) is unaffected since those rely on the CSS property directly.

Performance results

Measured via Chrome DevTools traces on a data cascade with ~40 visible rows, comparing the optimized implementation against the original baseline:

Category	Metric	Baseline	Optimized	Change
GC	Events	4,949	3,818	-23%
	Time	2,121 ms	2,099 ms	-1% (parity)
Layout	Style recalc time	722 ms	668 ms	-7%
	Layout time	47 ms	40 ms	-15%
Frames	P95 inter-frame gap	111 ms	111 ms	parity
	P50 FPS	59.9	59.8	parity

Key wins: GC events are 23% below baseline, layout/style costs are reduced, and the P95 inter-frame gap and median FPS are at parity. The architectural shift from N independent scroll handlers to a single coordinated listener also reduces the total number of scroll dispatch events by 26%.

Most importantly we are giving back rendering time to consumers of the component.

How to test

Verify that scroll sync works;
- Navigate to the storybook link that show cases the cascade rendering multiple stats, on resizing the viewport to the extent where the stats get clipped, hovering over any one of the rows should reveal the scroll button
- Clicking the scroll button should move all rows in the specified direction

eokoneyo · 2026-03-06T17:02:26Z

/ci

kibanamachine · 2026-03-06T17:35:53Z

Storybooks Preview

elasticmachine · 2026-03-07T00:04:04Z

Pinging @elastic/appex-sharedux (Team:SharedUX)

eokoneyo · 2026-03-07T00:05:46Z

@elasticmachine merge upstream

eokoneyo · 2026-03-09T08:05:55Z

@elasticmachine merge upstream

eokoneyo · 2026-03-09T09:10:25Z

@elasticmachine merge upstream

elasticmachine · 2026-03-09T10:33:01Z

💚 Build Succeeded

Buildkite Build
Commit: 183e42e

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
`discover`	1978	1979	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
`discover`	1.6MB	1.6MB	+1.7KB

History

💔 Build #406481 failed 662f525
💛 Build #406092 was flaky 71fc46e

cc @eokoneyo

kowalczyk-krzysztof

I like the changes but there's a lot of refs and listeners - could you check if everything works as expected on the consumer side by temporarily enabling React 18 concurrent mode in Discover (src/platform/plugins/shared/discover/public/application/index.tsx)?

eokoneyo · 2026-03-10T19:11:25Z

I like the changes but there's a lot of refs and listeners - could you check if everything works as expected on the consumer side by temporarily enabling React 18 concurrent mode in Discover (src/platform/plugins/shared/discover/public/application/index.tsx)?

Tested in concurrent mode, works well.

kibanamachine · 2026-03-10T19:12:17Z

Starting backport for target branches: 9.3

https://github.com/elastic/kibana/actions/runs/22919854670

kibanamachine · 2026-03-10T20:36:10Z

💔 All backports failed

Status	Branch	Result
❌	9.3	Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 256511

Questions ?

Please refer to the Backport tool documentation

## Summary This PR is part of the cascade performance improvement work(elastic#255745), culled from elastic#256037. Refactors the `ScrollSyncProvider` to eliminate per-row scroll overhead by centralizing scroll coordination into a single capture-phase listener with an allocation-free hot path. ### What changed - **Single capture-phase scroll listener**: Replaced N individual resize observers and `onScroll` React handlers (one per row) with a single native `scroll` listener attached at the provider's wrapper element using `{ capture: true, passive: true }`. This bypasses React's synthetic event system entirely for programmatic scroll events and uses a scroll-leader pattern to prevent the O(N^2) feedback cascade where each `scrollTo` write re-triggers handlers on all other rows. - **`useSyncExternalStore` for scroll state**: Replaced per-row `useState` + `onScroll` with a centralized pub/sub store. The provider computes three boolean flags (`isScrollable`, `canScrollLeft`, `canScrollRight`) and only emits to subscribers when the booleans actually change — not on every pixel of scroll. Consumers call `useSyncExternalStore(subscribe, getSnapshot)` for batched, stable re-renders. - **Cached layout dimensions**: `scrollWidth` and `clientWidth` are cached in the provider and only refreshed via `ResizeObserver` or on hover. The scroll hot path never reads these layout-forcing properties from the DOM. - **Zero-allocation scroll hot path**: All intermediate objects are mutated in place to minimize GC pressure: - Scroll state booleans are compared inline; a new snapshot object is only allocated when they change (~2-3 times per session, not per event). - A single reusable `ScrollToOptions` ref is shared across all `scrollTo` calls instead of allocating `{ left, behavior: 'instant' }` per container per event. - `cachedDimensions` are updated via property assignment, not object replacement. - `for...of` loops replace `.forEach` to avoid closure allocation. - The scroll-leader timeout callback is hoisted to a stable `useCallback` ref. - **Instant programmatic scrolling**: All programmatic `scrollTo` calls use `{ behavior: 'instant' }` to override the CSS `scroll-behavior: smooth` on scroll containers, ensuring synchronized rows update in the same frame as the leader. User-initiated smooth scroll (e.g. arrow button clicks) is unaffected since those rely on the CSS property directly. ### Performance results Measured via Chrome DevTools traces on a data cascade with ~40 visible rows, comparing the optimized implementation against the original baseline: | Category | Metric | Baseline | Optimized | Change | |---|---|---|---|---| | **GC** | Events | 4,949 | 3,818 | **-23%** | | | Time | 2,121 ms | 2,099 ms | **-1%** (parity) | | **Layout** | Style recalc time | 722 ms | 668 ms | **-7%** | | | Layout time | 47 ms | 40 ms | **-15%** | | **Frames** | P95 inter-frame gap | 111 ms | 111 ms | parity | | | P50 FPS | 59.9 | 59.8 | parity | **Key wins**: GC events are 23% below baseline, layout/style costs are reduced, and the P95 inter-frame gap and median FPS are at parity. The architectural shift from N independent scroll handlers to a single coordinated listener also reduces the total number of scroll dispatch events by 26%. Most importantly we are giving back rendering time to consumers of the component. How to test - Verify that scroll sync works; - Navigate to the storybook link that show cases the cascade rendering multiple stats, on resizing the viewport to the extent where the stats get clipped, hovering over any one of the rows should reveal the scroll button - Clicking the scroll button should move all rows in the specified direction  --------- Co-authored-by: Elastic Machine <elasticmachine@users.noreply.github.com>

kibanamachine · 2026-03-31T06:48:59Z