Experimental Event API: Remove TouchHitTarget SSR logic to prevent issues with mouse events #15381
Conversation
|
ReactDOM: size: 0.0%, gzip: 0.0% Details of bundled changes.Comparing: c25c59c...609f1d7 react-dom
Generated by 🚫 dangerJS |
There was a problem hiding this comment.
We have to be a bit careful here because any differences in the DOM will cause layout computation thrash and recalcs even though there's no visual change.
With partial hydration there are many commits and not just one big one. The constant overhead of layout/recalc adds up multiple times over. Since this is expected to be in almost every subtree, that means that every partial hydration commit will recalc which it didn't before.
I wonder what we can minimize the cost of this. E.g. if it's absolutely positioned, and maybe we can use CSS containment, it won't recompute anything around it. Another technique is to use pointer-events: none in the initial HTML and then only change that style property on hydration.
| // The logic that filters out mouse events from the hit slop | ||
| // is handled in event responder modules, which only get | ||
| // initialized upon hydration. | ||
| return ''; |
There was a problem hiding this comment.
Won't this cause a hydration warning now? Can you add back tests to ensure that SSR+hydration of a hit target actually still works?
This can also be problematic when this isn't the very last child of the parent. If there is a next sibling that's a div <Parent><HitTarget /><div /></Parent>, then we'll try to hydrate that sibling as the hit target instead of this one.
That's why I expected you to leave the div in place but without the top/left/bottom/right styles and then only add the styles in when we commit.
This PR removes affects the experimental event API and its behaviour when server side rendering
TouchHitTargets. Specifically, it changes the rendering so that hit slop elements are no longer serialized in SSR output. Instead we rely the hydration logic for theTouchHitTargetto add in the hit slop element to the client. This change comes after internal discussions with @sebmarkbage and @necolas, where we agreed this was the right change for now; we can revisit this again in the future if needed.This change fixes mouse events incorrectly firing before hydration has occurred. For example, if you have a
<button>that had aTouchHitTargeton it, it would render with an inner absolutely positioned<div>that "expanded" the hit boundaries of its parent<button>. We then handle mouse and touch events in the event responders, allowing touch events to use the expanded boundary as intended and filtering out mouse events (as they shouldn't use the expanded boundaries). Unfortunately, as this logic of filtering only gets initialized upon hydration of a component, the incorrect behaviour happens with mouse events on SSR content before this fix.Ref #15257