Developers, Here's How to Never Get Props vs State Stop Wrong

Every React dev messes this up at some point.
Even the experienced ones.

They build a component.
They pass data.
They store something in state… that doesn’t belong there.

Let’s clean this up once and for all.

The Big Picture

If you're confused about when to use props and when to use state, you’re not alone.
The rules seem blurry until you get a simple truth:

Props are for input.
State is for changes.

That’s it.

Still confused? Let’s break it down with code.

What Are Props?

Props are like function arguments.
You pass them into a component, and they stay the same unless the parent changes them.

function Welcome({ name }) {
  return <h1>Hello, {name}</h1>;
}

function App() {
  return <Welcome name="Sarah" />;
}

In this example:

• name is a prop.
• It’s passed from App to Welcome.
• Welcome cannot change name.

**Key rule: \ 👉 Props are read-only.

You use them to send data intoa component.
That’s it. Don’t try to change them inside the child.

What Is State?

State is internal.
It belongs to the component.
And it can change.

import { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}

In this example:

• count is a piece of state.
• setCount updates it.
• Only Counter controls it.

**Key rule: \ 👉 State is local and changeable.

Use state when your component needs to update over time—like handling user input, toggles, or fetch results.

The Mistake Everyone Makes

Let’s say you do this:

function Profile({ user }) {
  const [name, setName] = useState(user.name);
  // ❌ Wrong: copying props into state
}

Why is this wrong?

Because now you’ve duplicatedthe data.
Ifuser.name changes in the parent, this component won’t know.

Instead, just use the prop directly:

function Profile({ user }) {
  return <h2>{user.name}</h2>;
}

Use state only if you plan to edit or track changes.

Example where it's okay:

function EditableProfile({ user }) {
  const [name, setName] = useState(user.name);

  const handleChange = (e) => setName(e.target.value);

  return (
    <input value={name} onChange={handleChange} />
  );
}

Now you’re managing an input, so state is fine.

One Simple Rule To Remember

Here’s the one-liner that will help:

Props are what you get.
State is what you change.

Ask yourself:

• Is this data coming from a parent? → Props.
• Does it change inside the component? → State.
• Does it do both? → Use state, but be careful.

Real World Example

Imagine a todo list:

function TodoItem({ todo, onToggle }) {
  return (
    <li>
      <input
        type="checkbox"
        checked={todo.done}
        onChange={() => onToggle(todo.id)}
      />
      {todo.text}
    </li>
  );
}

Here:

• todo is a prop.
• onToggle is a callback prop.
• We don’t store todo.done in state—we trust the parent to manage it.

You’d only use state if this component had its own behavior, like managing whether it's being edited.

Final Thoughts

It’s easy to overthink props and state.
Just remember their roles:

• Props: external data, from the parent
• State: internal data, managed by the component

Most bugs come from mixing them up—especially copying props into state "just in case."

Keep it simple. Keep it clean.

React works best when you trust the data flow.

If this cleared things up for you, go refactor that component you weren’t sure about.
You probably don’t need that extra state after all.

Let the props do their job.
Let the state do its job.

And stop getting it wrong.