Warning for 'exhaustive-deps' keeps asking for the full 'props' object instead of allowing single 'props' properties as dependencies

[cbdeveloper]

Do you want to request a feature or report a bug?

BUG (possible) in eslint-plugin-react-hooks

What is the current behavior?

When I'm in CodeSanbox using a React Sandbox I can use single properties of the props object as dependencies for the useEffect hook:

Example 1:

useEffect(()=>{
    console.log('Running useEffect...');
    console.log(typeof(props.myProp));
  },[ ]);

The example 1 gives me the following warning in CodeSandbox environment:

React Hook useEffect has a missing dependency: 'props.myProp'. Either include it or remove the dependency array. (react-hooks/exhaustive-deps) eslint

And if I add [props.myProp] to the array, the warning goes away.

But the same example 1 in my local environment in VSCode, I get the following warning:

React Hook useEffect has a missing dependency: 'props'. Either include it or remove the dependency array. However, 'props' will change when any prop changes, so the preferred fix is to destructure the 'props' object outside of the useEffect call and refer to those specific props inside useEffect.eslint(react-hooks/exhaustive-deps)

What is the expected behavior?

I would expect that I would get the same behavior that I get on CodeSandbox in my local environment in VSCode.

But, if I add [props.myProp] to the array, the warning DOES NOT go away. Although the code works as intended.

What could be happening? Does CodeSandbox uses a different version of the plugin? Is there any configuration I can make to change this behavior?

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

Versions I'm using:

DEV:

"eslint": "^5.10.0",
"eslint-plugin-react": "^7.11.1",
"eslint-plugin-react-hooks": "^1.6.1",

REGULAR

"react": "^16.8.6",
"react-dom": "^16.8.6",

VSCODE (probably not causing this issue)

Version: 1.32.3 (user setup)
Commit: a3db5be9b5c6ba46bb7555ec5d60178ecc2eaae4
Date: 2019-03-14T23:43:35.476Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

.eslintrc.json

{
  "root"  :true,
  "env": {
    "browser": true,
    "commonjs": true,
    "es6": true,
    "node": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:import/errors"
  ],
  "parser":"babel-eslint",
  "parserOptions": {
    "ecmaVersion": 2018,
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx":true
    }
  },
  "plugins":[
    "react",
    "react-hooks"
  ],
  "rules": {
    "react/prop-types": 0,
    "semi": "error",
    "no-console": 0,
    "react-hooks/rules-of-hooks": "error",
    "react-hooks/exhaustive-deps": "warn"
  },
  "settings": {
    "import/resolver" : {
      "alias" : {
        "map" : [
          ["@components","./src/components"],
          ["@constants","./src/constants"],
          ["@helpers","./src/helpers"]
        ],
        "extensions": [".js"]
      }
    },
    "react" : {
      "version": "detect"
    }
  }
}

[cbdeveloper]

I understood what was going on. It's not a bug (I think).

This code:

useEffect(()=>{
  function someFunction() {
    props.whatever();                  // CALLING A FUNCTION FROM PROPS
  }
},[ ]);

Results in this warning:

React Hook useEffect has a missing dependency: 'props'. Either include it or remove the dependency array. However, 'props' will change when any prop changes, so the preferred fix is to destructure the 'props' object outside of the useEffect call and refer to those specific props inside useEffect. (react-hooks/exhaustive-deps)eslint

---

And this code:

useEffect(()=>{
  function someFunction() {
    props.whatever;                          // ACCESSING A PROPERTY FROM PROPS
  }
},[]);

Results in this warning:

React Hook useEffect has a missing dependency: 'props.whatever'. Either include it or remove the dependency array. (react-hooks/exhaustive-deps)eslint

---

I'm not sure why, but the plugin see it differently when you're calling a method from props or if your acessing a property from props.

The warning is pretty explicit , you should destructurate your props; since a re-render is made after a prop is changed

Please try

const myProp = props.myProp
useEffect(()=>{
    console.log('Running useEffect...');
    console.log(typeof(myProp));
  },[myProp );

[cbdeveloper]

@Admsol Yes, if you destructure it, it works. But I'm not a big fan of props destructuring. I like to always see that I'm accessing the props object anywhere.

I ended up assigning the method to a local variable (inside the useEffect) before calling it. Like:

useEffect(()=>{
  const whatever = props.whatever;
  whatever();
},[props.whatever]);

This way I get the proper warning (if I omit props.whatever from the array).

Otherwise, if I call props.whatever() directly, the "dependency omission" warning will be for the full props object instead of the props.whatever method.

Thanks!

[gaearon]

The reason plugin sees it differently is because by doing props.whatever() you are actually passing props itself as a this value to whatever. So technically it would see stale props.

By reading the function before the call you’re avoiding the problem:

const { whatever } = props;

useEffect(() => {
  // at some point
  whatever();
}, [whatever]);

This is the preferred solution.

Note: If whatever itself changes on every render, find where it is being passed down from, and wrap it with useCallback at that point. See also our FAQ.

[GeoMarkou]

Is there no better way to avoid this warning? @cbdeveloper 's solution works, but it feels like I'm going out of my way to change code just to please the linter, and no actual bugs are being prevented. If anything it makes the code worse, because it's no longer obvious that whatever belongs to the parent component. I can't imagine a situation where someone would use this inside props.whatever to access the other props?

[GeoMarkou]

Ok, after some learning on the horrible way that this works in JavaScript, I found a solution that fits my needs. To avoid destructuring the props object you have to explicitly call the function supplying your own this argument, otherwise it implicitly passes props. It even plays nicely with Typescript.

// Before
React.useCallback((event) => {
    props.onChange(event);
}, [props]);

// After
React.useCallback((event) => {
    props.onChange.call(undefined, event);
}, [props.onChange]);

[cbdeveloper]

This is still bugging me.

I've been using the following pattern to build some forms:

• I have a component to hold the state for the form
• The state is an object to hold details for a blogPost, for example.
• Each each child must access it and change
• So I'm passing down the setFormState method from the parent as props to all its child components.
• Each child component is responsible for its own function to update the state. So I lot of them do something like this:

function SomeTextInput(props) {

  const updateInput = useCallback((newInputvalue) => {
    props.setFormState((prevState) => {          // CALL 'setState' STRAIGHT FROM 'props'
      return({
        ...prevState,
        inputName: newInputvalue
      });
    });
  },[props.setFormState]);   // AND I GET THE ERROR ASKING FOR THE FULL 'props' INSTEAD OF THE METHOD THAT I'M CALLING

  return (
    <SomeInput/>
  );
}

And since I'm calling a method from props. I keep getting the error asking for the full props object instead of the method.

I don't think there's anything wrong with my pattern. I like to be explicit when I access something from props. I think it helps to know immediately that that property or method is coming from above in the tree. But I'm also opened to learn something new and useful if you guys can help me out.

What I end up doing is:

  const updateInput = useCallback((newInputvalue) => {
   const AUX_setFormState = props.setFormState;              // CREATE SOME 'aux' VARIABLE
    AUX_setFormState((prevState) => {
      return({
        ...prevState,
        inputName: newInputvalue
      });
    });
  },[props.setFormState]);

And the error goes away. But just like @GeoMarkou said, it feels like I'm going out of my way just to please the linter.

@gaearon I see that props becomes the this in the call. But how would I get stale props if I'm adding the specific props.method that I'm using to the dependency array of my useCallback?

Is there a way to "fix" this (not sure I can call this a bug)? I would vote to reopen this issue, if this fix is possible.

[GeoMarkou]

I also vote to re-open the issue if it's possible to fix. My co-workers are all ignoring this warning because there's no convenient way to make it happy, especially if you're calling several props methods.

[cbdeveloper]

@GeoMarkou I re-opened the issue. From time to time, this problem bugs me again.

[dacioromero]

This isn't only affecting props.

I have several hooks which return objects which have memoized callbacks (such as input controllers) and I would prefer not to destructure since renaming the destructured values gets very tedious.

Definitely would appreciate a solution. Maybe could be an option to ignore this specific type of warning?

[PezCoder]

I think the explanation the @gaearon #16265 (comment) mentioned totally makes sense & the plugin is completely right on throwing the error. But for cases where we know the function isn't working with this & that it won't change, this just executes the effect more than what is required.

Keeping the warnings open isn't an option in such cases, as follow up changes would require attention to what warnings to actually fix & what to let it be.

Since the purpose of plugin is to help developer avoid mistakes when using useEffect, a graceful way to skip these would really help. 🙏🏼

[lewisl9029]

The reason plugin sees it differently is because by doing props.whatever() you are actually passing props itself as a this value to whatever. So technically it would see stale props. By reading the function before the call you’re avoiding the problem.

I'm struggling to think of a case for which calling a function that depends on this (whatever in your example) and then passing this (props in your example) into the dependency list wouldn't already be ridiculously error prone.

By using a function that depends on this, you're likely also depending on in-place mutation of some internal state within this (i.e. a stateful class instance), which means even if this was passed into the dependency list, internal state changes within this would not trigger a rerun of the hook, which would likely lead to a whole class of bugs.

Is that really the use case we want to optimize for here? It honestly seems like an exercise in futility to me, so I would prefer if we just assumed that these functions don't depend on this and make these more-likely-to-be-correct usages of hooks more ergonomic.

[gaearon]

Is there a problem with destructuring those early? That’s the solution.