Understanding Components, Props, and State in React

Every React application, no matter how large, breaks down into the same three building blocks: components, props, and state. Meta’s own production codebase runs tens of thousands of components built from exactly this pattern, and the reason it scales is that the pattern itself is simple — the confusion beginners hit almost always comes from mixing up what each of the three actually owns.

Components: The Reusable Unit

A component is a JavaScript function that returns UI. Modern React is built almost entirely from function components rather than the older class component syntax, which is no longer the starting point for new code.

function ProductCard({ name, price }) {
  return (
    

      
{name}
      
${price}
    
  );
}

// Used like this, as many times as needed:

The entire point of a component is reuse: write the UI logic once, then render it with different inputs anywhere it’s needed.

Props: Data Flowing In, One Direction

Props (short for properties) are how a parent component passes data down to a child. They work exactly like function arguments — read-only from the child’s perspective, and the child cannot modify its own props directly.

function App() {
  const user = { name: 'Amara', role: 'Admin' };
  return ;
}

function UserBadge({ name, role }) {
  // name and role are read-only here — UserBadge cannot change them
  return {name} ({role});
}

This one-directional flow — data only moves from parent to child, never the reverse — is deliberate and is what makes React applications predictable to debug: a value can only have changed because whoever owns it changed it, not because some distant child component reached back and mutated it.

State: Data a Component Owns and Can Change

State is data that belongs to a component and can change over time — a form input’s current value, whether a modal is open, a counter’s current count. Unlike props, a component fully controls its own state and updates it with the useState hook:

function LikeButton() {
  const [liked, setLiked] = useState(false);

  return (
     setLiked(!liked)}>
      {liked ? '♥ Liked' : '♡ Like'}
    
  );
}

Calling setLiked doesn’t just update a variable — it tells React to re-render the component with the new value, which is the mechanism that makes the UI actually reflect the change on screen.

How the Three Work Together: Lifting State Up

A common early confusion is what to do when two sibling components both need access to the same piece of changing data. The answer is a pattern called “lifting state up”: move the state to their shared parent, then pass it down to both children as props, along with a function (also passed as a prop) that lets a child request a change.

function ShoppingCart() {
  const [items, setItems] = useState([]);

  return (
    <>
       setItems([...items, item])} />
      
    
  );
}
// State lives in ShoppingCart. ProductList triggers changes via onAdd (a prop).
// CartSummary just reads the current items (also a prop). Neither owns the state itself.

This pattern — state living as high as necessary but no higher, passed down through props, changed only through functions the owner explicitly hands out — is the actual architectural skill in React. Almost every confusing React bug in a real codebase traces back to state living in the wrong place, not to a misunderstanding of the useState syntax itself.

Frequently Asked Questions

Can a child component change its own props directly?
No, props are read-only from the receiving component’s perspective. If a child needs to trigger a change, the parent passes down a function as a prop, and the child calls that function rather than modifying the prop value itself.
When should data be state versus a prop?
If a component owns the data and needs to change it directly, it’s state (via useState). If the data comes from a parent and this component just displays or reacts to it, it’s a prop.
What does “lifting state up” actually solve?
It solves the problem of two sibling components needing access to the same changing data by moving that state to their shared parent, so there’s a single source of truth rather than each sibling maintaining its own disconnected copy.

Want more React deep dives like this? Explore more Web Development articles.