DEV Community

You (probably) don't need that useState + useEffect

Don Juan Javier on November 01, 2021

The useState and useEffect hooks were a godsend for the React community. However, like any tool, these can easily be abused. Here's one an example...

Read full post

João Lucas Silva • Nov 1 '21

The first approach is indeed wrong, because you should use useMemo for derived state, instead of useState+useEffect, the second approach is dangerous since it can lead to slow renders and infinite re-rendering, so if you are doing complex manipulation and/or passing the derived state down to another component you should use the derived state factories and place it inside a useMemo

Don Juan Javier • Nov 2 '21

If the calculations are expensive, then yes, useMemo would be ideal, however most derivations are quite trivial in my experience and using a pure function to compute takes less effort and cognitive load to set up. Also, pure functions are inherently easier to test as well. Thanks for the feedback!

João Lucas Silva • Nov 2 '21

You can declare the pure functions exactly the sema way, and test them as well, just wrap them inside the useMemo when calling, for me the golden rule is: if you are experienced, check your render times and render counts to decide using it or not, if you are a beginner and you are not sure always wrap derived state inside useMemo, because the using it when it is not needed will be negligible, but not using it when it is needed will give you so much headaches

leob • Nov 2 '21

I suppose "dangerous" only if those calculations are slow? if the time to execute them is negligible then useMemo would probably be overkill ... otherwise then yes, it would be the recommended approach :)

WEBKADABRA • Nov 3 '21

bro, the first code snippet has an error in it, I think:

useEffect(() => {
    setItems(data.items);
    setItems(data.items.length || 0);
  }, [data, setItems, setItemsLength]);

Shoultd it not be this instead:

useEffect(() => {
    setItems(data.items);
    setItemsLength(data.items.length || 0);
  }, [data, setItems, setItemsLength]);

Don Juan Javier • Nov 4 '21

Good catch! Made the correction. Important to test first before sending off to QA 😅

nvhung150196 • Nov 7 '21

setState in React is stable. You should remove them from the dependency array. I think array just like this [data]

devmeqa • Nov 4 '21

I'm new with React and I don't understand why isn't this code triggering an infinite loop ? (we watch for changes in setData and setData is called within the useEffect)

useEffect(() => {
someAsyncApiCall().then(res => {
setData(res.data);
setLoading(false);
});
}, [setData, setLoading]);

Don Juan Javier • Nov 4 '21 • Edited

UPDATE - see follow up below.

Your concern is 100% warranted - useEffect dependencies are often the cause of infinite loop headaches, mainly from objects, arrays, and function expressions.

The set* functions returned from the useHook call reference the same functions between renders. Or, in other words:

[useState and useEffect] are guaranteed to have a stable signature between renders

The following as you pointed out would cause an infinite loop:

// object
const user = {};
useEffect(() => { /* ... */ }, [user]);

const dogs = [];
useEffect(() => { /* ... */ }, [dogs]);

const fetchSomethingCool = () => {};
useEffect(() => { /* ... */ }, [fetchSomethingCool]);

Don Juan Javier • Nov 4 '21

UPDATE - I think that React does some smart memoization for the dependencies, so my analysis is incorrect. The main thing that would cause a useEffect is performing a setState (the same as using one of the set* useState functions) inside of a useEffect, where the state value is part of the dependency array.

This is a good article that outlines some of the pitfalls and how to solve them: dmitripavlutin.com/react-useeffect...

John Sawiris • Nov 2 '21 • Edited

Good article.👍
Though, there's one thing that I gotta mention. You don't need to include the state setters functions that are returned from useState in the useEffect dependency array, the reason being
that these function are guaranteed to have a stable signature between renders.

Don Juan Javier • Nov 3 '21

Good catch! I think the exhaustive-deps eslint rule used to complain if setter fncs were not included, so I just got into the habit if included everything in the dependency array, but you're absolutely correct (and eslint plugins have gotten a lot better over the years).

mohamed farid • Nov 6 '21

Thanks for this article

for me, the first approach is easier to reason about,
you see that items subscribe to changes of data,
but In the second approach, you can get messy
about why items are changing or when,
for the first approach using useMemo and
extracting logic to separate functions will make it better.

useMemo(() => {
    setItems(getItems(data));
    setItemsLength(getItemsLength(data));
  }, [data, setItems, setItemsLength]);

const getItems = (data) => {
  // I always like to protect against bad/unexpected data
  if (!data || !data.items) return [];

  return data.items;
};

const getItemsLength = (data) => {
  return getItems(data).length;
};

Don Juan Javier • Nov 12 '21

Thanks for the feedback. I'm not following how adding additional state and memoization helps to reason about the data. For me, simple data derivation is much easier to reason about, especially since there is less state being managed. As an app scales it especially becomes important to try and reduce complexity wherever possible.