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 state Props are for input.State is for changes. Props input State 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" />; } 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. name is a prop. name It’s passed from App to Welcome. App Welcome Welcome cannot change name. Welcome name **Key rule: \ 👉 Props are read-only. Props are read-only. You use them to send data intoa component.That’s it. Don’t try to change them inside the child. into 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> ); } 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. count is a piece of state. count setCount updates it. setCount Only Counter controls it. Counter **Key rule: \ 👉 State is local and changeable. 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 } 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. duplicated user.name Instead, just use the prop directly: function Profile({ user }) { return <h2>{user.name}</h2>; } function Profile({ user }) { return <h2>{user.name}</h2>; } Use state only if you plan to edit or track changes. state 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} /> ); } 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. 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. Is this data coming from a parent? → Props. from a parent Does it change inside the component? → State. change inside the component Does it do both? → Use state, but be careful. both 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> ); } 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. todo is a prop. todo onToggle is a callback prop. onToggle We don’t store todo.done in state—we trust the parent to manage it. todo.done trust the parent You’d only use state if this component had its own behavior, like managing whether it's being edited. own 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 Props: external data, from the parent Props State: internal data, managed by the component State 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.
