Lifting state up & basic styling

The problem

Two siblings need the same piece of state — a search box and a list, a filter and a table. They cannot see each other; React data only flows down. So the value moves up to the closest component that contains both, and comes back down as props.

function Page() {
  const [query, setQuery] = useState("");        // owned here

  return (
    <>
      <SearchBox value={query} onChange={setQuery} />
      <Results query={query} />
    </>
  );
}

function SearchBox({ value, onChange }) {
  return <input value={value} onChange={(e) => onChange(e.target.value)} />;
}

SearchBox now has no state of its own. It renders what it is given and reports what happened — which also makes it trivial to test and reusable anywhere.

Where should this state live?

1. Find every component that reads the value.
2. Find their closest common parent.
3. Put the state there. Pass the value down, pass a setter down.

Then stop. The instinct to put everything at the top of the app is the wrong one — state at the root re-renders the whole tree and makes every component below it dependent on a page it should not know about.

Prop drilling, and when it is actually a problem

Passing a prop through two or three layers is fine. It is explicit and you can trace it. It becomes a problem when a value crosses many layers that have no use for it — a theme, the signed-in user, a locale.

Two answers before you reach for a library: compose instead, by passing the finished element down as children so it never needs the prop in between; and context, for values that are genuinely ambient. Both are covered later; the mistake is jumping to a global store on the third prop.

Composition beats drilling

Before adding context, check whether the prop needs to travel at all. If the middle layers only pass it through, hand them the finished element instead.

// ✗ Layout and Sidebar both take a prop neither uses
<Layout user={user}>
  <Sidebar user={user}>
    <Profile user={user} />

// ✓ built at the top, passed as an element — nothing in between knows
<Layout sidebar={<Sidebar><Profile user={user} /></Sidebar>} />

The element is created where the data lives, so the layers it travels through carry it as opaque children. This removes most prop drilling people reach for a store to solve.

Colocation: keep state as low as it will go

The opposite of lifting, and just as important. A modal's open/closed flag belongs to the component that owns the modal, not to the page. State at the top of the tree re-renders everything below it and couples components that should not know about each other.

Lift when two components genuinely need the same value. Push it back down the moment only one does.

Styling: the four options

CSS Modules

// Card.module.css
.card { border: 1px solid #ddd; }
.title { font-weight: 700; }

// Card.jsx
import styles from "./Card.module.css";

<div className={styles.card}>
  <h2 className={styles.title}>{title}</h2>
</div>

The build renames .card to something unique per file, so two components can both have a .card without colliding. No naming convention to enforce, no cascade surprises.

Conditional classes

<button className={"btn " + (active ? "btn--active" : "")}>

<button className={["btn", active && "btn--active", size && "btn--" + size]
  .filter(Boolean)
  .join(" ")}>

Past two or three conditions, the clsx package does exactly this in one call and is worth the dependency.

Inline styles, and their limits

<div style={{ width: percent + "%", backgroundColor: color }} />

Right for a value computed at runtime, like a progress bar's width. Wrong as a general approach: no :hover, no @media, no ::before, and a new object every render.

Design tokens beat scattered values

:root {
  --ink: #1f3a73;
  --paper: #fffdf6;
  --radius: 12px;
}
@media (prefers-color-scheme: dark) {
  :root { --ink: #d9e5fb; --paper: #191d25; }
}

.card { background: var(--paper); color: var(--ink); border-radius: var(--radius); }

Custom properties cascade and can be swapped at runtime, so dark mode becomes a handful of redefinitions rather than a second stylesheet. Components read tokens and never literals — then a colour changes in one place, not forty.

This is worth setting up on day one of a project. Retrofitting tokens onto a codebase full of hex codes is a long afternoon.

Putting the tier together

With these ten chapters you can build a real screen: components composed from props, state where it belongs, events and conditions, lists with correct keys, a controlled form, and an effect for the one thing that genuinely needs to reach outside React.

The next chapter is where you do exactly that, end to end — a task board, built in the order a machine-coding round expects.

What you still cannot do is explain why it re-rendered. That is the intermediate tier — refs, context, memoisation, and the fetching patterns that do not race themselves — and it starts with useRef.