Who Owns This State?

The problem

Many interfaces get confusing because teams start creating state for everything before asking whether that value even needs to exist.

Very quickly, the same data appears in multiple places, one part of the screen depends on another to stay coherent, and users start reporting “random” bugs.

Most of the time, the problem is not React or Vue. The problem is that nobody made ownership clear.

Mental model

Good state is state with a clear owner.

If a value can be calculated from props or from other state, it usually should not be stored again.

If two parts of the UI depend on the same value, someone needs to be declared the single source of truth.

A simple way to think about it is:

• state is what needs to be remembered
• derived data is what can be recalculated
• bugs often show up when the two get mixed together

Breaking it down

When you look at a value in the UI, ask these questions:

1. Does this value really change because of user interaction or a network response?
2. Can I calculate it during render from what I already have?
3. Who is the source of truth for this value?
4. Does it actually need to be shared globally, or can it stay local?

Those questions prevent invented and unnecessary state.

They also help avoid another common mistake: lifting state too early. Not everything used in more than one place needs to become global. Sometimes it only needs to move one level up. Sometimes not even that.

Simple example

Imagine a page with a user list and a search box.

A messy approach stores three things:

• users
• searchQuery
• filteredUsers

The problem is that filteredUsers is not new truth. It is just the result of applying searchQuery to users.

A better model stores only:

• users
• searchQuery

and calculates the filtered list during render.

That removes manual synchronization and sharply lowers the chance of showing stale data.

Another common example is a modal with isOpen and selectedUser.

If the modal is only open when selectedUser exists, storing both can create nonsense states like:

• isOpen = true
• selectedUser = null

In many cases, storing only selectedUser is enough, and modal visibility can be derived from it.

Common mistakes

• storing state that could be derived during render
• creating two sources of truth for the same conceptual value
• lifting state to a parent or global store too early
• spreading shared state through the app without defining a clear owner

There is a subtler mistake too: copying a prop into local state just because it feels easier. Most of the time that only creates one more place where the value can get stale.

How a senior thinks

More experienced frontend engineers do not start by asking:

where should I put this useState?

They start by asking:

does this value really need to exist as state, or can I derive it from the truth I already have?

That question often simplifies the component before the first line of implementation.

Seniority shows up here in resisting the urge to model everything as mutable memory. Clear UI usually comes from having fewer things that need synchronization.

What the interviewer wants to see

In frontend interviews, this topic shows maturity quickly.

• You separate core truth from derived value.
• You respect the idea of a single source of truth.
• You can justify when state should stay local and when it should be shared.

A strong answer often sounds like this:

Before I create state, I try to figure out whether the value really changes because of some external event, or whether I can derive it from what I already have. If I can derive it, I usually prefer that because it reduces synchronization and inconsistency risk.

Storing too much state looks flexible on day one and becomes a synchronization mess soon after.