React props and state: Where your data should live

We’ve all been there: you’re deep into a component refactor, passing a userObject through five layers of components just to display a name in a footer. It feels messy, it breaks easily, and you realize you’ve created a maintenance nightmare.

The core of building scalable React applications isn't just knowing how to write useState or useEffect; it's mastering React props and state management. If you don't decide where your data lives early, your component tree will quickly become a tangled web of dependencies.

Understanding the "Source of Truth"

In React, data should flow one way: down. When you're deciding where a piece of state should live, ask yourself a simple question: "Does more than one component need to see this?"

If the answer is no, keep it local. If the answer is yes, you need to lift it up to the nearest common ancestor.

We once tried to manage form input state inside a deeply nested SubmitButton component. It worked for the initial prototype, but as soon as the design team asked for a "Reset" button in the header, the entire logic fell apart. We had to rewrite the state management entirely. Lesson learned: don't bury your state.

Props vs. State: The mental model

Think of props as the arguments you pass to a function, and state as the variables defined inside that function.

• Props: Immutable from the perspective of the child. They are the configuration for your component.
• State: The "memory" of your component. It changes over time, usually in response to user events like clicks or typing.

When you're working with React 19 upgrades: What you actually need to know for production, you’ll find that cleaner state management helps you leverage new features like the use hook and improved server-side integration much more effectively.

How to structure React props and state

When you’re stuck deciding where data belongs, use this hierarchy:

1. Local State (useState): Use this for UI-specific things like toggling a dropdown or tracking a text input.
2. Parent State: If two siblings need the same data, move the state to their parent.
3. Global/Context State: If you're passing data through five+ layers, stop. Use React Context or a library like Zustand.

Here is a common scenario—a simple counter shared between two components:

JSX
// The wrong way: duplicating state in both components
// The right way: Lift the state to the parent
function Dashboard() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <Display count={count} />
      <Controls increment={() => setCount(c => c + 1)} />
    </div>
  );
}

By keeping the state in Dashboard, both Display and Controls remain "dumb" or presentational components. They don't care how the count changes; they just receive the data they need via props.

When things get messy

Sometimes, you'll encounter a situation where you need data from an API. If you are extending the WordPress REST API with custom endpoints, remember that your frontend shouldn't be responsible for transforming that raw data.

Fetch the data in a top-level component, keep it in state, and pass it down as props. If you start trying to fetch data inside every leaf node, your app will suffer from "waterfall" loading issues, causing performance to tank—often adding around 300ms to 500ms of unnecessary latency per component request.

Frequently Asked Questions

Why shouldn't I just put everything in Context?

Context is great for global settings like themes or user authentication. If you put everything in Context, you'll trigger re-renders across your entire app every time a single value changes. Keep your state as local as possible.

How do I know if I'm "prop drilling"?

If you find yourself passing a prop through a component that doesn't actually use it—just to get it to a child—you're prop drilling. It’s a sign that your component composition needs a rethink.

What about useEffect?

useEffect is for syncing your state with external systems (like an API or the DOM). Don't use it to sync state between two variables inside your component; that's almost always a sign that you should just derive the value during render instead.

Final thoughts

I’m still refining my own approach to state. Sometimes I hold onto local state for too long because I'm lazy, only to pay the price when I have to refactor it later. Don't be afraid to pull state up the tree as soon as you realize a second component needs access to it. It feels like extra work in the moment, but your future self—and your code—will thank you for it.