react-hooks/exhaustive-deps frequently shows a warning for objects returned from custom hooks

[florianmartens]

There's a lot of content on this but I'm confused 😵‍💫. The eslint rule react-hooks/exhaustive-deps throws a warning when we put nested properties from hook-returned objects into the dependency array.

Here's the problem:

// ✅ Allowed
const obj1 = {a: "abc"};
useMemo(() => obj1.a, [obj1.a]);

// ✅ Allowed  
const obj2 = useMemo(() => ({a: "abc"}), []);
useMemo(() => obj2.a, [obj2.a]);

// ❌ Not allowed
const obj3 = useDisclosure();
useMemo(() => obj3.onOpen, [obj3.onOpen]); // missing dependencies: 'obj3'

One of the issues where this is described is #24300 . @gaearon wrote that the reason this is forbidden has to do with useDisclosure's return value needing to be immutable.

However, this does not make sense. In the example above: obj1 is just as mutable as obj3. And overall, I fail to see why the mutability of the enclosing object matters in the first place. In my head, it is the reference to the function onOpen that matters. The fact that I'm allowed to de-structure the value further illustrates this:

// ✅ Allowed
const { onOpen } = useDisclosure();
useMemo(() => onOpen, [onOpen]);

I'm struggling to understand this and can't find any clear reason why we can't have a nested property from a hook-returned object as a dependency.

[SametDulger]

Hi,

This is a common source of confusion when dealing with react-hooks/exhaustive-deps.

The core issue is how React's hook dependency arrays check for changes. They rely on referential equality — meaning if the reference to a value changes, React treats it as different.

Let's break down your examples:

When you do

const obj1 = {a: "abc"};
useMemo(() => obj1.a, [obj1.a]);

obj1 is a stable reference, and obj1.a is a primitive, so no problem.

When you do

const obj2 = useMemo(() => ({a: "abc"}), []);
useMemo(() => obj2.a, [obj2.a]);

Here, obj2 is memoized and stable, and obj2.a is a string literal, so fine.

But with a custom hook like useDisclosure(), it likely returns a new object on every render, so obj3 is a fresh object each time, even if obj3.onOpen itself is stable or memoized inside.

The rule suggests adding the entire obj3 to dependencies because React can’t guarantee that just watching obj3.onOpen is enough. The object might be replaced with a new one, and some other properties could change or cause side effects.

Destructuring like this:

const { onOpen } = useDisclosure();
useMemo(() => onOpen, [onOpen]);
works because you’re now depending directly on the stable onOpen reference, not the whole object.

Why does the enclosing object’s mutability matter?
Because React’s hooks compare the dependency references shallowly. If the enclosing object changes reference every render, React will warn if you only specify nested properties but not the object itself.

In short:

If your hook returns a new object every render, you either need to:

Destructure the properties you want and depend on those directly, or

Memoize the entire returned object inside the hook to keep references stable.

[gaearon]

#34092 (comment)