🧩 Thinking in React: When and Where to Create State (Explained with a Packing List App)

This content originally appeared on DEV Community and was authored by Usama

Managing state is one of the most confusing parts for new React developers — we often wonder:

“Should this be a state, a prop, or a ref?”

In this post, I’ll break down a simple decision-making process to know when to create state and where to put it — using my own small project called Listo , a packing list app built with React.

When to Create State

Ask yourself a few questions before creating new state.

1⃣ Do I need to store some data?

• No: Just use a normal variable.

  const total = price * quantity;

• Yes: Go to the next question.

2⃣ Can this data be computed from existing state or props?

If yes, then don’t store it separately — derive it instead.

Example:

const packedCount = items.filter(item => item.packed).length;

No need to store packedCount in useState; it’s derived from items.

3⃣ Should updating this data re-render the component?

• No: Use a ref instead (useRef).

  const inputRef = useRef();

Refs store data without triggering a re-render.

• Yes: Go ahead and create local state.

  const [items, setItems] = useState([]);

Example: My “Listo” App

Here’s how the logic applies to my packing list app.

import { useState } from "react";

function App() {
  const [items, setItems] = useState([]);

  function handleAddItem(item) {
    setItems((items) => [...items, item]);
  }

  return (
    <div className="app">
      <Logo />
      <Form onAddItem={handleAddItem} />
      <PackingList items={items} />
      <Stats />
    </div>
  );
}

Where to Place State

Once you decide you need state, the next question is where to keep it.

1⃣ Is it only used inside one component?

Keep it local.

function Form() {
  const [description, setDescription] = useState("");
}

2⃣ Is it needed by a child component?

Keep it in the parent and pass it down via props.

<Form onAddItem={handleAddItem} />

3⃣ Is it needed by multiple siblings?

Then lift the state up to their common parent.

In the Listo app:

• The Form needs to add new items.
• The PackingList needs to display those items.

Solution: Keep items state in the App component and share it via props.

4⃣ Is it used everywhere in the app?

If many unrelated components need it, you’re dealing with global state.

Use:

• React Context API
• or a library like Zustand, Redux, or Jotai

The Flowchart (Simplified)

Need to store data?
 ├── No → Use const
 └── Yes
      ├── Can it be derived from props/state?
      │     └── Yes → Derive it
      └── No
           ├── Should it re-render component?
           │     └── No → useRef
           └── Yes → useState

Where to place state?
 ├── Used only by this component → keep local
 ├── Used by a child → move to parent
 ├── Used by siblings → lift to common parent
 └── Used globally → global state (context / redux)

Key Takeaways

1. Don’t overuse state — derive values when possible.
2. Lift state up when multiple components need it.
3. Refs are great for mutable values that don’t trigger re-renders.
4. Always ask: “Who needs this data?” — the answer tells you where the state should live.

Bonus: The “Listo” App in Action

Example list item rendering:

<li>
  <span>
    {item.quantity} {item.unit} — {item.description}
  </span>
</li>

Output:

2 kg — Apples

Final Thoughts

Thinking in React means thinking about data flow.

When you understand who owns the data and who needs it, managing state becomes simple, predictable, and fun.

“If two components need the same data, lift it up.
If only one needs it, keep it local.
If it doesn’t affect rendering, use a ref.”

Written by [Usama]
Web Developer sharing my React learning journey
Built with React: “Listo” – a simple but powerful packing list app

This content originally appeared on DEV Community and was authored by Usama