Confusion with useEffectEvent lint rules

[snowystinger]

I am unsure how to convert some of our code as a result of the new compiler settings.

Say I have a component

function Component () {
  let onResize = useEffectEvent(() => {
    // ...
  });
  useEffect(() => {
    document.fonts?.ready.then(() => onResize())
  });
  useResizeObserver(ref, onResize);
}

I'm currently getting an error on the line with the useResizeObserver. However, I know that the useResizeObserver is safe, as its implementation is (simplified):

let useResizeObserver = (ref, onResize) => {
  useEffect(() => {
    const resizeObserverInstance = new window.ResizeObserver((entries) => {
      if (!entries.length) {
        return;
      }

      onResize();
    });
    resizeObserverInstance.observe(element, {});
     return () => {
      if (element) {
        resizeObserverInstance.unobserve(element);
      }
    };
  }, [ref, onResize])
}

where the onResize is only ever called from something inside the useEffect.

I've added the useResizeObserver hook to the eslint settings as shown in the docs, however, there's nothing that indicates which values are safe or not to be a useEffectEvent. There also doesn't seem to be a way to document this in the types or... anywhere?
https://react.dev/reference/eslint-plugin-react-hooks/lints/rules-of-hooks#options
Also, the lint wants useEffectEvent to be removed from the useEffect dependency array. But that's impossible in a hook that is generalised like this one. You can see I've included it in the dependency array above because I don't know if someone will or already is passing non-useEffectEvents to it.

I feel like I'm not supposed to use this setting here, but I'm not sure what I should be doing instead.

Some other considerations I had:

• Copy the code inside useResizeObserver directly over to my usage, but this will duplicate in many places in our codebase.
• I could have two copies of the function effectEvent one that's a useEffectEvent and one that is a useCallback, but sometimes effectEvent is large and duplicating it would mean that drift might occur in addition to the messy extra copy.

[gaearon]

I think the first thing you'd want to do is to tweak your Hook.

let useResizeObserver = (ref, onResize) => {
+  const onResizeEvent = useEffectEvent(onResize)
  useEffect(() => {
    const resizeObserverInstance = new window.ResizeObserver((entries) => {
      if (!entries.length) {
        return;
      }

-      onResize();
+      onResizeEvent();
    });
    resizeObserverInstance.observe(element, {});
     return () => {
      if (element) {
        resizeObserverInstance.unobserve(element);
      }
    };
-  }, [ref, onResize])
+  }, [ref])
}

Then it doesn't care whether the passed onResize is stable or memoized.

In the calling code, you could do this:

function Component () {
  function onResize() {
    // ... your logic goes here ...
  }

  const onFontsReady = useEffectEvent(onResize);
  useEffect(() => {
    document.fonts?.ready.then(onFontsReady)
  }, []);

  useResizeObserver(ref, onResize);
}

Does that help?

[snowystinger]

Ah, that does. Thank you immensely. I think I stared at that much too long.

[snowystinger]

I've got another one. How are we meant to handle a case like this. We want to attach a global listener to track mouse movement starting on mouse down, as it tracks movement, we want to always call the latest event from props.

export default function MyApp(props) {
  // want to make sure the latest version of props.onMove is called
  let onMove = useEffectEvent(() => props.onMove());

  return (
    <button
      onMouseDown={() => {
        window.addEventListener('mousemove', onMove);
      }}>
      Test
    </button>
  );
}

[gaearon]

The pattern is currently scoped to effects because it’s too easy to unintentionally lose reactivity in other cases.

You could translate this pattern to an effect by adding isDown state and having the effect attach/detach event based on that state. (This should also help ensure you clean up the listener.)

[snowystinger]

I think I have a much worse understanding of the word reactivity than I originally thought.

I don't quite follow why

<button
  onMouseDown={() => {
    window.addEventListener('mousemove', onMove);
  }}>
  Test
</button>

// is different from

let ref = useRef(null);
useEffect(() => {
  ref.current.addEventListener('mousedown', () => {
    window.addEventListener('mousemove', onMove);
  });
})
<button ref={ref}.../>

At least as far as the compiler is concerned. I've omitted cleanup to keep the example short, but maybe that's the important bit.

I've resolved all the transformations for rules-of-hooks now in our repo though with that pointer. Thank you very much for the help with that.

[gaearon]

I’m not saying this specific case is worse. The problem is that it’s easy to wrap something in this abstraction near the top, pass it down through multiple levels, and then eventually somebody wants to use it in an effect that should be reactive (e.g. not as an event, but as part of effect’s logic). Then this becomes a massive pitfall because somebody working on the code above can make the code close over some props/state that changes, but the code below would have no way at all to “react” to those changes. Forcing effect events to be declared next to their effects avoids this problem because the decision to opt out of reactivity is always next to the code that depends on that reactivity.