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.

[anndreii15-hash]

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.

Originally posted by @florianmartens in #34086

[gaearon]

I think my response was specific to the motivation the OP post (which mentioned mutation).

What is the exact error message you’re seeing? And what happens if you try to follow it? And what is the real example you’re dealing with? That would help thinking about this.

[josephsavona]

This case is an error because of how JavaScript works. When you do obj.onOpen(), React has to assume that you’re calling a prototype method, that “onOpen()” is part of the objects prototype. If that’s the case, even when the object changes, the method will still be the same. Consider something like arrays:

const array1 = [];
const array2 = [];
array1 === array2; // false
array1.map === array2.map; // true!

This means that in general, it isn’t safe to take a dependency if something looks like a method call. As the array example shows, the object might change but the dependency on the method being called may not change.

If you know that’s not the case - if you know that obj.onOpen() is a static function that doesn’t access anything from obj and isn’t part of its prototype chain - then you can extract it to a separate variable first:

const onOpen = obj.onOpen;
const … = useMemo(() => onOpen(), [onOpen]);

[ZunedKhan07]

Hey! 👋 I’d love to work on this. Just wanted to confirm if a PR would be welcome for this fix?

[josephsavona]

@ZunedKhan07 This isn't a bug, and next steps need further discussion.

[gaearon]

I think this issue report is subtly mistaken.

Quoting the opening post:

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

That's not true. The above snippet, verbatim, is allowed and does not cause errors. This is easy to verify (e.g. by pasting it into a sandbox on the React docs site):

What does fail is this:

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

Note I've added () to actually make it a method call.

This does fail:

And it should because as @josephsavona noted, obj3.onOpen() in JavaScript means something like obj3.onOpen.call(obj3), and obj3 is itself an implicit argument (and so it is unsafe to omit).

If you're sure you're not relying on the implicit this value, you can destructure onOpen outside useMemo. Then you're explicitly removing obj3 from the call, and thus no longer need to memoize it.