Infinite loop in useEffect using blank object or array

[eashish93]

Using React Version: 16.8.4
When using blank object or array as a setter for function inside useEffect does cause infinite loop. However using string or number does not trigger this. Here's the minimal example:

function Example() {
  const [count, setCount] = useState(0);
  const [foo, setFoo] = useState({});

  useEffect(() => {
     console.log("Infinite Loop");
     setCount(100);    // doesn't cause infinite loop.
     // but this does
     // setFoo({});   // or setFoo([]);
  });

  return <div />;
}

I don't know if it's a bug or default behaviour because in earlier version of react (in v16.7.0-alpha.0), both string and number also causing infinite loop which seems to be fixed in latest one.

[mlandalv]

It seems to behave according to the docs.

If you update a State Hook to the same value as the current state, React will bail out without rendering the children or firing effects.

Both {} and [] creates a new object or array and hence triggers an update. 100 is primitive and doesn't.

[eashish93]

Hmm, this is actually the case, but IMO react should not create new object every time if it doesn't change (which causing infinite loop). Otherwise we don't have a way to update state with object without adding dependency array. Consider this real world example:

 
     function Example() {
        const [currentUser, setCurrentUser] = useState({});
        useEffect(() => {
              const unsub = firebase.auth().onAuthStateChanged(user => {
                  unsub();
                  if(user) setCurrentUser(user);
              });
        })
       return <div/>
     }

Now we don't have a way to avoid infinite loop in this case without adding setCurrentUser or currentUser.uid in dependency array.

[mlandalv]

You can avoid your infinite loops yourself by using more conditions before calling setCurrentUser, .e.g.

const unsub = firebase.auth().onAuthStateChanged(user => {
    unsub();

    // Do nothing if the user hasn't changed.
    if (user && currentUser && user.username === currentUser.username) {
        return;
    })

    setCurrentUser(user);
});

[mlandalv]

I haven't used firebase myself but by the looks of it you you may be able to do something like this:

function Example() {
    const [currentUser, setCurrentUser] = useState({});

    useEffect(() => {
        const unsub = firebase.auth().onAuthStateChanged(user => {
            // Do nothing if the user hasn't changed.
            if (user && currentUser && user.username === currentUser.username) {
                return;
            }

            setCurrentUser(user);
        });

        // Unsub when the componenent unmounts.
        return () => unsub();
    }, []); // Empty array so this effect only is called on mount and unmount.

    return <div/>;
}

[eashish93]

passing condition in dependency array and checking explicitly is the same thing.

[kunukn]

I believe it is the default behaviour. React does shallow comparing. Passing a {} will fail the shallow compare.

I believe the best strategy is to pass a dependency if there is a dependency on when the effect should run.

There is these fresh articles I highly recommend to read

However, when you run your application, you should stumble into a nasty loop .... Because we are setting the state after every data fetch, the component updates and the effect runs again. It fetches the data again and again. That’s a bug and needs to be avoided

• https://www.robinwieruch.de/react-hooks-fetch-data/ - by Robin Wieruch

• https://overreacted.io/a-complete-guide-to-useeffect/ - by Abramov

[gaearon]

Re: example in #15096 (comment), you can fix it by adding the dependencies argument. (In this case, it's [] because your effect doesn't depend on any values from render scope except setCurrentUser which is guaranteed to be stable.)

     function Example() {
        const [currentUser, setCurrentUser] = useState({});
        useEffect(() => {
              const unsub = firebase.auth().onAuthStateChanged(user => {
                  unsub();
                  if(user) setCurrentUser(user);
              });
        }, []) // <--------- I added this
       return <div/>
     }

Note that you should only do it when it's safe — i.e. when you don't use any props/state and values derived from them in the effect, and you also don't call any functions that use those.

See:

• https://reactjs.org/docs/hooks-effect.html#tip-optimizing-performance-by-skipping-effects
• https://www.robinwieruch.de/react-hooks-fetch-data/

Hope this helps.

For a deeper dive:

• https://reactjs.org/docs/hooks-faq.html#is-it-safe-to-omit-functions-from-the-list-of-dependencies
• https://reactjs.org/docs/hooks-faq.html#what-can-i-do-if-my-effect-dependencies-change-too-often
• https://reactjs.org/docs/hooks-faq.html#why-am-i-seeing-stale-props-or-state-inside-my-function

[keithpickering]

This was closed years ago but I believe it's a bug according to how React handles the same value in other scenarios.

This causes an infinite loop:

export function App({
  someArray = []
}) {
  const [s, setS] = React.useState(1);

  React.useEffect(() => {
    setS(s + 1);
  }, [someArray])

  return `Rendered: ${s} times`;
}

As others have mentioned, this is because [] is a new array on every render, hence it triggers the useEffect infinitely.

However, if we add a separate component and pass someArray into it while keeping the default [] value, the loop is fixed:

const Component = ({ someArray }) => {
  const [s, setS] = React.useState(1);

  React.useEffect(() => {
    setS(s + 1);
  }, [someArray])

  return `Rendered: ${s} times`;
}

export function App({
  someArray = []
}) {
  return <Component someArray={someArray} />;
}

So React seems to be performing a more complex comparison at the component level, at which point it rationalizes that [] is "equal" to [] for the purposes of needing to trigger a re-render.

I believe extra logic should be added to useEffect so it can intelligently determine that, for all intents and purposes, [] === [] and {} === {} (even though both are technically false). This feels more in line with how we're supposed to think about and use dependency arrays.