React Props Best Practices

In the last lesson, React Component Composition with Props, you learned to pass components and content around. This lesson is a short set of habits that keep those props readable and your components easy to change later.

🎯 Destructure props for readability

When a component receives props, you can pull the values out right at the top. That is called destructuring, and it just means grabbing named values out of the props object.

Here is why you want to do it:

• It tells the reader, in one line, exactly what data this component needs.
• You stop writing props. again and again in the JSX, so the code gets shorter.
• A new person reading the file can understand the inputs without scrolling.

This example shows the same component written both ways so you can feel the difference.

// ❌ Harder to read - props. everywhere
function UserCard(props) {
  return (
    <div>
      <h2>{props.name}</h2>
      <p>{props.email}</p>
    </div>
  );
}

// ✅ Clean - you can see the inputs at a glance
function UserCard({ name, email }) {
  return (
    <div>
      <h2>{name}</h2>
      <p>{email}</p>
    </div>
  );
}

🔒 Keep props read-only

A prop is data the parent owns and hands down to the child. The child is allowed to read it and show it. The child is not allowed to change it. We say props are read-only.

Why this rule matters:

• The parent is the one source of truth for that value. So if the child changes it secretly, the parent and child now disagree.
• React decides when to re-render by watching data flow downward. Mutating a prop breaks that flow and gives you bugs that are very hard to find.
• When data needs to change over time, that is the job of state, not props. You will learn state in the very next lesson.

This pair shows the mistake and the safe way to do the same thing.

// ❌ Never do this - mutating a prop
function PriceTag({ price }) {
  price = price * 1.1; // changing the prop directly
  return <p>Price: ${price}</p>;
}

// ✅ Right - read the prop, make a new local value
function PriceTag({ price }) {
  const finalPrice = price * 1.1; // a new variable, prop untouched
  return <p>Price: ${finalPrice}</p>;
}

🏷️ Give props clear descriptive names

A prop name should say what the value is, so the person using your component does not have to guess. A good name is self-explaining.

Habits that keep names clear:

• Use a real word, not a short code. isActive beats a.
• For true/false values, start with is, has, or can. Like isLoggedIn or hasDiscount.
• For functions you pass down, start with on. Like onClick or onSubmit. People expect that.

This pair shows a confusing name next to a clear one.

// ❌ What is "d"? What is "flag"? Nobody knows
<ProductCard d="Wireless Mouse" flag={true} />

// ✅ The names say exactly what they are
<ProductCard title="Wireless Mouse" inStock={true} />

🎚️ Provide default values for optional props

Some props are optional. If the parent does not pass them, the value comes in as undefined. Instead of letting that happen, you can set a default value right where you destructure.

Why defaults help:

• The component still works even when the parent forgets to pass something.
• You avoid empty gaps and undefined showing up in your UI.
• The default tells the reader what the normal, expected value looks like.

Here we give role and theme sensible fallbacks.

// ✅ Defaults sit right in the destructuring
function Button({ label, theme = "light", role = "secondary" }) {
  return (
    <button className={`btn ${theme} ${role}`}>
      {label}
    </button>
  );
}

// Used without theme or role - the defaults kick in
<Button label="Save" />

📦 Don’t over-pass props

Pass a child only the data it actually uses. Sending a whole big object when the child needs one field is what we call over-passing, and it causes real problems.

Why less is better:

• The child gets tied to the shape of a big object it barely touches. So change the object later and the child can break.
• Reading the component, you cannot tell what it really depends on.
• Smaller, specific props make the component easy to reuse somewhere else.

This pair passes the whole user object versus just the two fields the child needs.

// ❌ The badge needs only a name, but gets the entire user object
<UserBadge user={user} />

function UserBadge({ user }) {
  return <span>{user.name}</span>; // ignores everything else
}

// ✅ Pass only what it uses
<UserBadge name={user.name} />

function UserBadge({ name }) {
  return <span>{name}</span>;
}

🧱 Keep components focused

A component should do one clear job. When you keep it focused, its list of props stays short and easy to read. A long prop list is usually a sign the component is trying to do too much.

Watch for these signs:

• The function takes ten or more props. Time to split it into smaller pieces.
• The props belong to different jobs, like layout plus data plus form handling all in one.
• You keep adding “just one more” prop every week.

Here a bloated component is split into two focused ones.

// ❌ One component juggling too many unrelated jobs
function Dashboard({ user, posts, theme, onLogout, onSearch, cartItems }) {
  // header stuff, feed stuff, cart stuff... all mixed together
}

// ✅ Split by job - each piece has a short, clear prop list
function Header({ user, onLogout }) { /* ... */ }
function Feed({ posts }) { /* ... */ }
function Cart({ cartItems }) { /* ... */ }

⚠️ Prop drilling is a smell

Sometimes you pass a prop down through several components that do not use it themselves. They only hand it further down. That is called prop drilling, and it is a sign something needs cleaning up.

Why it becomes a problem:

• The middle components carry props they do not care about, just to pass them along.
• Rename one prop and you have to edit every component in the chain.
• The deeper the chain, the harder it is to follow where the data is actually used.

A quick picture of the chain:

App  →  Layout  →  Sidebar  →  ProfileButton
 |        (just     (just        (finally
 user      passes    passes       uses user)
           user)     user)

You do not need to fix this today, just learn to notice it. React gives you two clean ways out, and you will meet them soon:

• Lifting state up when a couple of nearby components need to share a value.
• Context when a value, like the logged-in user or the theme, is needed all over the tree.

🧩 What You’ve Learned

• ✅ Destructure props in the function parameters so the inputs are clear at a glance
• ✅ Props are read-only - read them, never change them; use state when data must change
• ✅ Give props clear, descriptive names (is/has for booleans, on for handlers)
• ✅ Set default values for optional props so the component always works
• ✅ Don’t over-pass - send a child only the data it actually uses
• ✅ Keep components focused so their prop lists stay short
• ✅ Prop drilling is a smell that state-lifting and Context will solve later

🚀 What’s Next?

You now know how to keep props clean, clear, and read-only. But props only flow one way, downward. Data that changes while the app runs, like a counter or a form input, is exactly what state is for, and it is the next big idea in React.

React State