PointerLeave event listener not fired across renders

[dbismut]

This is a bit of an edge case and might be the logical expected behavior.

When adding two pointerleave events listeners to a ref interleaved with renders, the second pointerleave doesn't fire.

pointerleave.mov

The top square has a ref which gets two pointerenter and two pointerleave listeners that trigger a render by changing the component state. The listeners are added (and cleaned) on every render in a useEffect hook.

The bottom square has onPointerEnter and onPointerLeave props that also trigger a render by changing the component state.

As you can see from the video above, the behavior of the top square is different depending on whether the mouse exits to the background or to the bottom square.

React version: 17.0.2

Steps To Reproduce

From the demo below:

1. Hover the top square
2. Hover the bottom square

Link to code example:
https://codesandbox.io/s/use-gesture-react-use-hover-bug-forked-gpr0r

The current behavior

When hovering the bottom square, the top square has hovering1 set to false and hovering2 set to true.

The expected behavior

When hovering the bottom square, the top square should have both hovering1 and hovering2 set to false.

[billyjanitsch]

I believe this is expected (if strange) behavior. It will be "fixed" in React 18 because of the switch to batching state updates that are enqueued in the same tick.

The way that your codesandbox is arranged makes it seem like there's some difference between React-owned event handlers and imperatively-attached ones, but that's a red herring. Here's a simpler repro with only one square:
https://codesandbox.io/s/use-gesture-react-use-hover-bug-forked-fuiim?file=/src/App.jsx

Hovering over the square results in the first two state values being set to true but the last one remaining false. My understanding of what happens is roughly the following:

1. The initial render enqueues and then executes the effect (1), attaching three pointerenter listeners to the element.
2. On hover, the pointerenter event bubbles to the element where:
   1. The event is handled by the first listener, which triggers the first setState, which triggers a re-render, which enqueues a new effect (2) but doesn't immediately run it yet.
   2. The event is then handled by the second listener, which triggers the second setState, which triggers another re-render. Triggering a re-render while there are pending effects forces a flush of the effects queue, which calls the cleanup function from effect (1). This cleanup function unregisters the pointer listeners.
   3. The event is therefore not handled by the third listener because that listener has been unregistered by the time it would be.

React's order of operations can seem counterintuitive here but it's a consequence of making useEffect as lazy as possible for performance reasons while still upholding the guarantee that effects will be ordered correctly with respect to each other. (You can switch my codesandbox to useLayoutEffect to force the effect queue to flush even earlier, resulting in only the first state value being set to true.)

Different workarounds are available depending on what you're actually trying to do. You basically want to avoid having an event listener call code that will unregister another listener for the same event.

[dbismut]

Hi @billyjanitsch thanks for the detailed explanation, the switch from useLayoutEffect to useEffect is good to know. I guess you may be in a situation where you want to register the same event with a different event capture flag. I'm maintaining https://github.com/pmndrs/use-gesture where these situations can happen, but I can manage something. Thanks for the help though, I will see what happens in React 18.

[stale]

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

[github-actions]

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!