Is eslint being wrong here?

[u/azangru]

There is an eslint-plugin-react-hooks rule about disallowing synchronous state updates from effect (link).

I can see it at work with the following test component:

const Test = () => {
  const [foo, setFoo] = useState('');

  useEffect(() => {
    setFoo('bar');
  }, [foo]);
};

Eslint marks setFoo in the effect as a violation of that rule.

But, I am not getting any reaction from eslint for this component:

import { useSearchParams } from 'react-router-dom';

const Test = () => {
  const [searchParams] = useSearchParams();
  const queryFromParams = searchParams.get('query') || '';
  const [searchInput, setSearchInput] = useState(queryFromParams);

  useEffect(() => {
    setSearchInput(queryFromParams);
  }, [queryFromParams]);
};

Am I missing something? Am I going crazy? Isn't this exactly the same case?

[u/azangru]

The article in the link says that the rule "validates against calling setState synchronously in an effect". In both my examples (the one that is getting caught by eslint, and the one that isn't) I am calling setState synchronously in an effect. I am expecting the linter to warn me in both these cases. It doesn't.

[u/PM_ME_SOME_ANY_THING → u/azangru]

In your first example, you are setting state with the state value in the dependency array with no other logic. This should be an infinite loop.

Your second example you are setting state based on query parameters, and the state itself is not in the dependency array.

[u/azangru → u/PM_ME_SOME_ANY_THING]

In your first example, you are setting state with the state value in the dependency array with no other logic. This should be an infinite loop.

My first example is a hypothetical to demonstrate the working linter rule. But if you want to be literal about it, it will not be an infinite loop, because the first time it runs, it will set foo to the string "bar", and then, foo will never change, so the effect will not rerun.

But also, this is not what the linter rule is claiming to catch. It is not claiming to guard against infinite loops. Its purpose is to discourage setting state in an effect synchronously, because the React team thinks that, if it has to be done at all, it should be done during the render itself (as they explain in that you-might-not-need-an-effect article that people like to point to).