blog/dont-over-use-state

[utterances-bot]

Don't over useState | TkDodo's blog

The first part of the useState pitfalls series is all about avoiding state altogether. Lots of things might not even be state after all...

https://www.dorfmeister.cc/blog/dont-over-use-state

[danialdezfouli]

Thank you,

But assuming we have to fetch an API call for the categories based on data, we still need that useEffect

[TkDodo]

For data fetching, i can recommend react-query 😉

[chiptus]

@danialdezfouli and if not react-query, IMO just use both fetches in one useEffect

[JulesBlm]

I noticed the "Thinking in React" from the old React docs made it in to the new beta docs too. That's good because it's one of the best intro's to React IMO. I did notice a small change though.

Ask three questions about each piece of data:

1. Is it passed in from a parent via props? If so, it probably isn’t state.
2. Does it remain unchanged over time? If so, it probably isn’t state.
3. Can you compute it based on any other state or props in your component? If so, it isn’t state.
   Old React Docs - Thinking in React

Was changed to:

Ask three questions about each piece of data:

1. Is it passed in from a parent via props? If so, it isn’t state.
2. Does it remain unchanged over time? If so, it isn’t state.
3. Can you compute it based on any other state or props in your component? If so, it definitely isn’t state!
   Beta React Docs - Thinking in React

Notice the differences? The 'probably's are gone and a definitely was added: "If so, it definitely isn’t state!"

Ambiguity be gone! And rightfully so. I think the React docs team realized this is a common mistake, as affirmed by your blogpost.

[TkDodo]

oh right, that is a pretty sneaky, but solid change. I wrote the blogpost because I've seen it done "wrong" every so often, and yes, I'm sure the react team has also seen that. It's important to communicate that understanding 🙌

[gonstoll]

Could there be an exception to your postulation? If categories depends on data, but also is going to be tied to an input element? I.e:

function App() {
  const [data, setData] = React.useState(null);
  const [categories, setCategories] = React.useState<string[]>([]);

  React.useEffect(() => {
    async function fetch() {
      const response = await fetchData();
      setData(response.data);
    }
    fetch();
  }, []);

  React.useEffect(() => {
    if (data) {
      setCategories(computeCategories(data));
    }
  }, [data]);

  return (
    <>
      ...
      <input
        value={categories.join()}
        onChange={e => setCategories([e.target.value])}
      />
    </>
  );
}

[TkDodo]

That example shows another classic gotcha with effects and local state, especially forms. If setData is called again, the effect will run again, thus re-setting categories, even though the user might have already written something in the input field, which might overwrite the users data.

[fatihcandev]

Idk why there'd be a use case like this but you could keep a state of the input instead and create the categories depending on that. like:

const [value, setValue] = React.useState<string>("");

const categories = useMemo(() => [inputValue], [inputValue])

<input
        value={categories.join()}
        onChange={e => setInputValue(e.target.value)}
      />

[fatihcandev]

and this is kinda off-topic and maybe an over-optimization for a case like this but you could also re-render the input only when categories change. just a reminder :) this kinda optimizations can be leveraged from in larger projects with many components

const input = useMemo(() => (
   <input
        value={categories.join()}
        onChange={e => setInputValue(e.target.value)}
      />
), [categories])

[gonstoll]

@fatihcandev your example wouldn't work, you're missing the point in the sense that categories actually comes from a fetch. In your example categories is never synchronised with the fetched data.
Here, I've quickly put a sandbox example today to better explain the issue. See especially the EditPost component over there.
In a few words, I need to have an input with fetched data values that can also be edited. I really don't want to use an Effect for this but I don't see any other way to accomplish it :(
Keep in mind I'm working with a UI library that already handles controlled inputs.

[vlack-coder]

Thanks for this nice article... I was just wondering if I can just simplify everything like this:
👇🏽

const App = () => {
  const [data, setData] = React.useState([]);

  React.useEffect(() => {
    async function fetch() {
      const response = await fetchData();
      setData(computeCategories(response.data));
    }
    fetch();
  }, []);

  return <>...</>;
};

[TkDodo]

sure, that works for this example. If you only care about the computed value, you can also store that as your data. In react-query terms, this would be whatever you return from the queryFn, which can also be pre-transformed.

However, if you need the raw data to compute multiple different things in different ways, the takeaway is to only store the "base" that everything has in common, and then derive the rest. Like, if you have a todo list, you would only store the raw list of todos. If someone needs the count of finished todos, they would derive it from there. If someone needs the name of the latest todo, they would also derive it.

[pankajpatel]

Good writeup, thanks for writing this.

I personally think of as less state as possible and if your component has too many state related operations then it should not have JSX. Whole rendering should be pushed to a new component which just reflects on props. More like Controller and View layer.

And if there are too many useState, can you combine them in a useReducer; this forces me to think of state derivatives in terms of data instead of React.

[hungify]

I love this quote <3.

Don't prematurely optimize, always measure first.