Props: Passing Data In

"Components let you split the UI into independent, reusable pieces, and think about each piece in isolation." — React documentation

You already know how to write a function that takes arguments and returns a value. A React component is exactly that — a function that takes one argument and returns UI. That single argument is called props, and it is the entire mechanism by which a parent component hands data down to a child. Master props and you have the vocabulary for every conversation React components ever have with one another. It is also the first thing an interviewer probes, because how a candidate talks about props reveals whether they understand React's deepest rule: data flows one way, and children never reach back up to change what they were given.

Core Concepts

A component is a function; props is its parameter object. When you write <Greeting name="Ada" />, React calls your Greeting function and passes it a single object — { name: "Ada" }. That object is the props. Every JSX attribute you write becomes one key on that object. There is no magic here: rendering a component is calling a function with an argument, and props is that argument.

The syntax for passing props has exactly one rule worth memorising: string literals use quotes; everything else uses curly braces.

Look at the console: the attributes arrived as a plain object. name="Ada" is a string, so quotes are fine. But age={36} needs braces — without them, age="36" would pass the string "36", not the number. And isAdmin on its own is shorthand for isAdmin={true}, the same way an HTML boolean attribute works. The braces are a window from JSX back into JavaScript; anything you can put in a variable, you can put between them.

Reading props: the object, or destructuring

Inside the component you can reach into the props object (props.name), but idiomatic React destructures props right in the parameter list. It reads cleaner and documents, at a glance, exactly what the component consumes:

Both styles receive the identical object; destructuring simply names the fields you care about up front. From here on we will destructure by default, as nearly all React code does.

Props are read-only — this is the rule that defines React

A component must never mutate its props. Props are immutable from the child's point of view: they are input, not scratch paper. Writing props.name = "Bob" (or props.items.push(x)) is a bug, even when it seems to "work."

Why so strict? Because React's entire model rests on one-way data flow: data flows down from parent to child, and only the owner of a piece of data may change it. If any child could rewrite its props, you could never look at a parent and know what its children are displaying — the data on screen would depend on hidden edits happening three levels deep. Keeping props read-only makes rendering predictable: the same props always produce the same UI, every time, which is what lets React re-render safely and what lets you reason about a component in isolation. (When a component genuinely needs data that changes over time, that data belongs to the component as state — the subject of Part III. The distinction is precise: props come from above and are read-only here; state is owned here and is the only thing this component may change.)

Props carry any type — including functions

A prop can hold anything a JavaScript variable can: strings, numbers, booleans, objects, arrays, and — crucially — functions. Passing a function down is how a child sends information back up without ever mutating anything: the parent owns the data and the handler, and simply lends the child a button to press.

Click a button and watch the console. The child never touched fruits or invented its own data — it called the function the parent handed it. That callback pattern is the teaser for the next Part, Events: this is precisely how a child "talks back" while data flow stays strictly one-way.

Default values with destructuring

A parent may omit a prop. Rather than guard against undefined everywhere, give the prop a default value in the destructuring — plain JavaScript default-parameter syntax, which you already know:

The default fires only when the prop is undefined (i.e. not passed). Pass tone={null} explicitly and the default does not apply — null is a value.

Typing props with TypeScript

You finished Volume 2, so type your props — it is the single highest-value habit in a real React + TypeScript codebase. Declare a type (or interface) describing the props object and annotate the parameter. The compiler now enforces the component's contract: forget a required prop, or pass a number where a string belongs, and you learn at the call site, not at runtime.

The ? marks a prop optional; the default in the destructure supplies its value when omitted. That pairing — optional in the type, defaulted in the signature — is the standard, self-documenting way to declare a prop the caller may skip.

Common Mistakes

• Mutating a prop. props.count++ or items.push(x) inside a child. It corrupts the one-way flow and often does nothing visible — the parent's data is untouched. Read props; never write them.
• Forgetting the curly braces. age="36" passes the string "36"; you meant age={36}. Only string literals take quotes; every other type needs {}.
• Confusing props with state. Props come from the parent and are read-only here. State is owned by this component and is the only thing it may change. Reaching for props when you mean state (or vice-versa) is the classic beginner tangle.
• Passing a called function instead of the function. onClick={handle()} runs handle during render and passes its return value. You almost always want onClick={handle} or onClick={() => handle(arg)}.
• Relying on || for defaults. count || 10 turns a legitimate 0 into 10. Use destructuring defaults ({ count = 10 }), which trigger only on undefined.
• Spreading props blindly. <Child {...everything} /> is convenient but hides the contract and can forward props the child shouldn't get. Prefer naming what you pass.

Interview Corner

Chapter Summary

• A component is a function; props is its single parameter object, built from the JSX attributes the parent writes.
• Pass string literals in quotes and everything else — numbers, booleans, objects, arrays, functions — in {}. A bare attribute means ={true}.
• Read props from the object (props.x) or, idiomatically, by destructuring in the parameter list.
• Props are read-only. Never mutate a prop; it breaks one-way data flow and makes rendering unpredictable. Props come from above; state (Part III) is owned here.
• Give optional props defaults in the destructure — they trigger only on undefined, unlike ||.
• Function props (callbacks) let a child signal back up without mutating anything — the teaser for Events.
• Type props with a type Props = { … } so the compiler enforces the component's contract.

Editorial reflection — props feel almost too simple to dwell on — you're just passing arguments to a function. But the read-only rule sitting on top of that simplicity is one of the most consequential design decisions in modern software. It says: data has an owner, it flows one way, and no one downstream may rewrite history. Everything React gives you — predictable renders, components you can reason about alone, a tree you can trace from the top — is rent paid by that one constraint. Internalise it now, while the examples are small, and the large ones will never surprise you.