Props vs state in React

Two ways data lives in a React component.

Props. Input from the parent. Read-only.

function Avatar({ user, size }: { user: User; size: number }) {
  // user and size are props — set by the caller, can't be reassigned here
  return <img src={user.avatarUrl} width={size} />;
}

State. Internal, owned by the component, mutated via a setter.

function Counter() {
  const [count, setCount] = useState(0); // state
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

Data-flow rules.

1. Props flow down. Parent → child, never the reverse.
2. Events flow up. Children call callbacks passed down as props; the parent decides what to do with them.
3. State lives at the lowest common ancestor of the components that need it. This is called lifting state.

// Two siblings need the same temperature value.
function App() {
  const [temp, setTemp] = useState(0);
  return (
    <>
      <Slider value={temp} onChange={setTemp} />
      <Display value={temp} />
    </>
  );
}

temp lives in the parent because both children need it. The slider takes it as a prop and reports changes via a callback prop.

The two rules that matter most.

1. Don't put derived data in state.

```tsx // Bad — derived state. fullName drifts out of sync. const [first, setFirst] = useState(""); const [last, setLast] = useState(""); const [fullName, setFullName] = useState(""); // ← don't

// Good — compute on render. const fullName = ${first} ${last}; ```

If you can compute it, do — every render is cheap, and you eliminate a class of "I forgot to update X when Y changed" bugs.

1. Don't copy props into state without a reason.

``tsx // Usually wrong function Field({ value }) { const [internal, setInternal] = useState(value); ... } ``

The component now ignores future changes to value from the parent. Use it directly. Copy into state only when you genuinely want to fork the value (e.g., a draft for editing that the user can cancel).

When you DO want to mirror a prop into state.

The "uncontrolled-with-controlled-reset" pattern:

<Editor key={item.id} initialValue={item.text} />

Inside, useState(initialValue) is fine, because key={item.id} forces a remount when the parent's selected item changes — so internal state always starts from the right prop.

Props can be functions, objects, JSX. Anything. Children-as-prop is common:

<Card title="Hi">
  <p>body</p>
</Card>
// Inside Card, you receive a `children` prop with the <p> element.

Context bypasses the prop chain — but it's not state. It's a way to deliver a value (which itself is state somewhere up the tree) to deeply nested consumers without manual prop drilling.

Senior framing. The mental model is: state is the minimum amount of mutable input the component needs to remember between renders. Everything else is either a prop (passed in) or a derived value (computed during render). Most "why is my component buggy" questions trace back to having too much state — variables that should have been derived.