Props and composition

Why this matters

Yesterday you split a dashboard into three components and passed a few values in. Today you learn the rules of that channel properly. Props are how data and configuration travel into a component, and getting the boundaries right is the difference between four small components you can reuse and one 300-line file nobody dares touch.

By the end of the hour your equipment cards will all come from one component fed different data — no copied markup anywhere.

Props are the inputs to the block

A component function receives exactly one argument: an object holding every attribute written on the tag. That object is called props, short for properties.

<SummaryCard label="Total units" value={42} />

React calls your function with { label: "Total units", value: 42 }. You almost always destructure it in the parameter list, and you type it with a named type alias (Day 33):

type SummaryCardProps = {
  label: string;
  value: number;
  hint?: string;      // the ? makes it optional
};

export function SummaryCard({ label, value, hint }: SummaryCardProps) {
  return (
    <article className="card">
      <h2>{label}</h2>
      <p className="card-value">{value}</p>
      {hint && <p className="card-hint">{hint}</p>}
    </article>
  );
}

Three details worth naming:

• Quotes pass a string; braces pass a value. label="Total" is the string "Total". value={42} is the number 42. items={equipment} passes the array itself. Getting these mixed up is the single most common early TypeScript error here.
• hint? is optional, so hint is string | undefined inside the component. TypeScript will make you handle the undefined case — that is Day 32 narrowing doing its job.
• {hint && <p>...</p>} renders the paragraph only when hint has a value. React renders nothing for undefined, null, false, and true, which is why this idiom works.

One-way data flow

Props travel in exactly one direction: parent to child, down the render tree. There is no way for a child to hand data back up by writing to props.

This constraint is the reason a React app stays readable. When some text on screen is wrong, you look at the component that rendered it, see which prop supplied it, then look at that component's parent, and repeat. The trail always leads upward to one place where the value was decided.

children: content between the tags

Some components wrap other content rather than describing it. For those, React gives you a special prop named children, holding whatever you put between the opening and closing tags.

import type { ReactNode } from "react";

type PanelProps = {
  title: string;
  children: ReactNode;
};

export function Panel({ title, children }: PanelProps) {
  return (
    <section className="panel">
      <h2>{title}</h2>
      {children}
    </section>
  );
}

<Panel title="Needs attention">
  <EquipmentList items={urgent} />
</Panel>

ReactNode is the TypeScript type for "anything React can render": elements, strings, numbers, arrays of those, null. Import it with import type, which tells the compiler this import disappears at build time.

children is what makes composition possible. Panel knows nothing about equipment — it provides a heading and a box, and the caller decides what goes inside. That one component now works for equipment, maintenance records, and anything you build in Week 10.

Rendering a list

Cards come from data, so you map over an array (Day 22) and get back an array of elements.

type EquipmentListProps = {
  items: Equipment[];
};

export function EquipmentList({ items }: EquipmentListProps) {
  if (items.length === 0) {
    return <EmptyState message="No equipment matches this view." />;
  }

  return (
    <ul className="equipment-list">
      {items.map((item) => (
        <li key={item.id}>
          <EquipmentCard item={item} />
        </li>
      ))}
    </ul>
  );
}

Two things to fix in your head:

key. Every element produced by a list needs a key prop holding a string that is stable and unique among its siblings. React uses it to match elements between renders — without it, React guesses by position, and reordering or deleting an item can move state onto the wrong row. Use the data's real id. Do not use the array index if the list can ever be reordered or filtered.

The early return. A component can return different trees for different inputs. Handing the empty case to a dedicated EmptyState component keeps the main path clean and gives you one place to write a helpful message.

Component boundaries

Splitting is a judgement call, but three signals are reliable.

Repeated markup. The same five lines of JSX written twice is a component waiting to be extracted. Once extracted, a change lands in one file instead of two.

Two jobs in one function. If a component both fetches-and-filters data and paints a detailed row, the row is doing work unrelated to its own display. Split it.

Props that expose internals. This is the subtle one. Compare:

<StatusBadge backgroundColor="#c00" textColor="#fff" borderRadius={4} />   // leaky
<StatusBadge status="down" />                                              // clean

The first makes every caller responsible for knowing how a badge is built, so changing the badge design means editing every call site. The second describes what the thing is and lets the badge decide how to look. Good props state meaning, not mechanism.

Resist the opposite failure too. Extracting a component used exactly once, with eight props that are just its own markup passed through, adds a file and hides nothing.

Walkthrough

Build StatusBadge, the smallest useful component in the app. Create src/components/StatusBadge.tsx:

import type { Equipment } from "../types";

type StatusBadgeProps = {
  status: Equipment["status"];
};

const LABELS: Record<Equipment["status"], string> = {
  ok: "Operational",
  "needs-service": "Needs service",
  down: "Down",
};

export function StatusBadge({ status }: StatusBadgeProps) {
  return <span className={`badge badge-${status}`}>{LABELS[status]}</span>;
}

Equipment["status"] reads the type of one field out of the Equipment type — so if you add a status to types.ts later, TypeScript flags this file rather than letting it drift. Record<K, V> is the built-in generic for an object with keys K and values V; because K is the status union, leaving a status out is a compile error.

Note what the badge renders: text, not just a colour. A colour-only badge is unreadable for anyone who cannot distinguish those colours, and invisible to a screen reader — the Week 2 rule, applied to components.

Now use it in a card:

export function EquipmentCard({ item }: { item: Equipment }) {
  return (
    <article className="equipment-card">
      <h3>{item.name}</h3>
      <p>{item.location}</p>
      <StatusBadge status={item.status} />
    </article>
  );
}

Your turn

Deliverable: components that render different data without copied markup.

1. Create src/components/StatusBadge.tsx exactly as in the walkthrough. Add three CSS rules for .badge-ok, .badge-needs-service, and .badge-down in src/index.css.
2. Create src/components/EquipmentCard.tsx taking a single item: Equipment prop.
3. Create src/components/EmptyState.tsx taking message: string and an optional children?: ReactNode for an action. Render the message in a <p>.
4. Rewrite EquipmentList to map over items with key={item.id} and return <EmptyState /> when the array is empty.
5. In App.tsx, render the list twice: once with your full array and once with []. Confirm the second shows the empty state. Then delete that second copy.
6. Build a Panel component with title and children, and wrap your list in it.
7. Search your src folder for duplicated JSX. Any block appearing twice becomes a component.

Common pitfalls

• Forgetting braces on non-string props. value="42" passes the string "42"; TypeScript reports Type 'string' is not assignable to type 'number'. Braces for anything but a literal string.
• Using the array index as a key. key={index} looks fine until you filter or reorder, then rows keep the wrong state. Use a stable id.
• Mutating a prop. items.push(...) inside a child changes the parent's array with no re-render, so the screen and the data silently disagree.
• One component per file taken too far. Three components in one file is fine while they belong together. Split when a file is hard to navigate, not on principle.

Verify it yourself

Open today's reference, React's Learn section, and find the pages on passing props and on rendering lists.

1. React documents a way to forward every prop at once with the spread syntax {...props}. Find it, and write one sentence on why it can make a component's interface harder to read.
2. The lists page explains what happens when keys are missing or duplicated. Find what React says about using the array index, and compare it with this lesson's claim.

Record both in notes/day-58.md. Where the docs and this lesson agree, you now have two sources; where you can state the exception yourself, you have understanding.