perf(cdk-experimental/column-resize): add debounce to column header h…

[danielolaru91]

…over to prevent excessive handler rendering

This PR improves the user experience and performance of the cdk-experimental column resize feature by adding a debounceTime operator to the headerCellHoveredDistinct observable. Previously, the hover event triggered the handler immediately, which could result in unwanted handlers showing up when the user quickly moved their cursor over column headers. This change ensures that the handlers only appear if the user pauses (hovers for 300ms) over the column header, preventing handlers from rendering during fast cursor movements.

Why this change is suggested:

The previous implementation immediately triggered the column resize handlers as soon as the user hovered over the column header, which could be distracting or lead to unnecessary renders when the user quickly moves the cursor across the page. By adding a debounceTime(300), we ensure that the hover event only triggers the handler after the user has paused over the column header for at least 300ms, reducing the number of handler renders and making the interaction feel smoother.

This change prevents the handlers from appearing if the user is simply passing by the headers or trying to reach another element, improving the overall experience, especially when navigating fast through the UI.

Changes:

• Added debounceTime(300) to the headerCellHoveredDistinct observable to delay the rendering of handlers until the user has hovered over the header for 300ms.

[danielolaru91]

@andrewseguin @kseamon When you have a moment, please take a look at this change. It improves performance, especially in UIs with a large number of DOM nodes and multiple table instances with resizable columns.

Right now, when a user moves their cursor across the screen—say from the top of the UI to an element at the bottom—they may unintentionally trigger the rendering of all the resize handlers in each table header they pass over. This happens even if they don’t intend to interact with those columns.

In DOM-heavy interfaces, this can lead to noticeable performance issues. This update minimizes unnecessary rendering and should make the UI feel more responsive in those scenarios.

Would love your feedback—thanks!

[kseamon]

In concept, this looks fine. Played with it a bit. I think 300ms is too long - maybe try 100?

[danielolaru91]

In concept, this looks fine. Played with it a bit. I think 300ms is too long - maybe try 100?

Thanks for checking it out! Totally hear you on the 300ms—while it's just a fraction of a second and barely noticeable to the human eye, I agree that it might be on the higher side for this use case.

I tried out 200ms as a middle ground, and it feels like a good balance between responsiveness and avoiding unnecessary handler rendering. Would you be okay with going with 200ms?

Happy to adjust further if needed!