Removing the dependency array in useEffect

[guillaumebrunerie]

What are the plans for using the React Compiler to remove the need for having a dependency array in useEffect?

It feels like it would be pretty easy to have the compiler automatically inject all the right dependencies, and surely this has been discussed internally. Although I guess there are backwards compatibility issues with the fact that not having a dependency array currently means running the effect after each render.

[poteto]

Great question! You are right that the compiler's analysis gives us a solid foundation to automatically figure out dependencies. What's hard about this is not the compiler implementation, but more so the overall design of effects. We're looking at it holistically across both the runtime and compiler.

It's not baked enough for us to share concrete details at this point in time, but this is something we're well aware of and have been doing a lot of active research on. Several of us are working on the useEffect space currently. I hope we can share more soon!

[matthewdavi]

Curious about the status of this @poteto, especially given this blog post from earlier this year:

When we released hooks, we knew we could make them easier to use with ahead-of-time compilation. With the React Compiler, you’re now able to avoid writing useCallback and useMemo yourself in most cases. For Effects, the compiler can insert the dependencies for you:

The post makes it seem like the compiler can already do this, but as far as I can tell, it doesn't do this and the blog post is misleading.

[julianthurner]

Considering how dependencies for useCallback and useMemo are handled, which is, developers simply don't use them and the Compiler inserts them automatically where appropriate, it seems natural that finding a solution for useEffect dependency arrays would be more difficult.

With useCallback and useMemo, you can simply omit them and let the Compiler insert them automatically where appropriate. This works because the Compiler just memoizes the already existing functions / variables. The same approach wouldn't work for useEffect, since you still need to declare the Effect itself somewhere. Which begs the question: How can we omit the dependency array and have the Compiler automatically track dependencies?

Here's what I'd suggest:

Introduce a hook called something like useCompilerEffect:

const useCompilerEffect = (f: EffectCallback) => {
    throw new Error(
        'This hook can only be used within components / hooks that are optimized by the React Compiler.'
    );
};

Then, when you use it like this:

useCompilerEffect(() => {
    doSomethingWithFoo(foo);
});

It will throw if the React compiler isn't enabled for that component / hook. If the Compiler optimizes it, it transforms the call into:

useEffect(() => {
    doSomethingWithFoo(foo);
}, [doSomethingWithFoo, foo]);

This would be quite a minimal change and allows for incremental adoption.

The main problem with this is approach is what happens when the compiler silently skips a component. I'd suggest making this a build error instead of silently skipping it, forcing developers to either resolve the issues that lead to skipping the component or to explicitly opt out of optimization by putting a "use no memo"; at the top of the component / hook so developers know that this component isn't being optimized by the compiler.

We had to manually implement a React Compiler logger in our project that fails the build whenever a component is silently skipped. Otherwise, developers might skip manual memoization, assuming the component / hook is already being optimized by the Compiler when it actually isn't.

I think this should be the default behavior: If a component is expected to be optimized but the compiler silently skips it, developers should be made aware through a build failure rather than having it happen silently.