Props: Passing Data Between Components

Components in the React for Beginners series are useful because they are configurable: the same function can render a thousand different cards, avatars or rows. The mechanism for passing configuration from parent to child is called props — short for properties. This chapter covers passing data, reading it with destructuring, applying defaults, and the one rule you must never break.

Props are function arguments

Underneath the JSX, a component is an ordinary function, and props are simply its first parameter. Writing <UserCard name="Ada" role="admin" /> is equivalent to calling UserCard({ name: 'Ada', role: 'admin' }). JSX attribute syntax is just a friendly way to supply that object:

function UserCard({ name, role }) {
  return (
    <article className="card">
      <h3>{name}</h3>
      <p>Role: {role}</p>
    </article>
  );
}

export default function App() {
  return <UserCard name="Ada" role="admin" />;
}

Expected output:

Ada
Role: admin

Destructuring in the parameter list ({ name, role }) unpacks the props object — the same destructuring you may know from objects and JSON.

Passing different kinds of data

Because JSX attributes are JavaScript, you can pass anything by placing it in braces. Strings can be written bare (role="admin"); every other type needs braces.

Omitting a value for a boolean prop passes true, which is why <Button disabled /> works.

Defaults and optional props

Real components accept optional inputs. Default parameter values in the destructuring give you safe fallbacks, and the logical OR operator handles empty cases:

function Badge({ label, tone = 'info', count = 0 }) {
  const text = count > 0 ? `${label} (${count})` : label;
  return <span className={`badge badge--${tone}`}>{text}</span>;
}

// Used three different ways:
// <Badge label="Inbox" />              → Inbox
// <Badge label="Inbox" count={12} />    → Inbox (12)
// <Badge label="Errors" tone="danger" count={2} />

Expected output:

Inbox
Inbox (12)
Errors (2)

Props drive the UI

The same component renders differently per parent — that is the entire point. A status widget can receive a variant prop and branch on it, keeping presentation decisions next to the markup they affect:

function Status({ state, message }) {
  if (state === 'loading') return <p role="status">Loading…</p>;
  if (state === 'error') return <p className="error">{message}</p>;
  return <p className="ok">{message}</p>;
}

Expected output: whichever branch matches the prop — Loading…, the message in red, or the message in green. Parents own the data; children own the markup.

The read-only rule

Props are read-only. A component never writes to the object it received; to change something, the owner of the data updates its own state and passes new props down (chapter 6 and chapter 11 explain the mechanics). React enforces the spirit of this rule — reassigning name = 'Ravi' inside UserCard throws in StrictMode's development checks. Unidirectional data flow is what makes an application debuggable: to find where a value came from, you walk up the tree, never sideways.

Children: props you write as markup

Anything nested between a component's tags arrives as props.children — a single prop holding elements. It is why wrappers like <Card><h2>…</h2></Card> work. Chapter 14 is devoted to this pattern; here it is enough to know that children are ordinary props.

Common mistakes

• Typo in a prop name — nmae="Ada" silently yields undefined; React will not warn about an unknown prop.
• Passing a string where a number is expected — count="12" plus arithmetic gives string concatenation; use count={12}.
• Mutating props inside the child — props belong to the parent; derive new values instead of editing the received object.
• Calling a callback prop during render — onSave={save()} runs immediately; pass onSave={save} and let the child decide when.
• Boolean shorthand confusion — remember disabled means true; disabled="false" is actually truthy.

Practice checklist

1. Build a Badge with label, tone and count defaults; render it three ways with different data.
2. Pass an array of strings and render one list item per element with map.
3. Pass a callback prop and log it from the child using console.log (without calling it).
4. Intentionally misspell a prop, observe the undefined output, then fix it.
5. Draw a parent-child data flow diagram: which arrows carry props, which carry callbacks?

Props flow down, but something must change for the UI to respond — meet state in State with useState.