With CicloUrbano's catalogue genuinely filtering now, App is starting to grow: sections to wrap, notices to show, panels that repeat with small variations. Anyone coming from Java, C# or PHP has an automatic reflex here: create a base class BasePanel and have CataloguePanel and BookingsPanel inherit from it. In React that reflex is the wrong one. The official documentation is explicit: no use case has been found where component inheritance is preferable to composition. In this lesson you'll learn why, and what's used instead: children, named slots, configuration-based specialization, render props, and higher-order components, ending with a single rule that settles every reuse decision you'll make in React.

1. Why React doesn't use component inheritance
2. Composition with children: generic containers
3. Named slots: several props that receive JSX
4. Configuration-based specialization: from Notice to MaintenanceNotice
5. children as a function: render props
6. Higher-order components (HOC): how to read them
7. Comparison table of the five techniques
8. The practical rule: compose the interface, extract the logic
9. Central example: the catalogue screen, recomposed

Classic inheritance solves reuse by saying "B is an A, and it also does this other thing." It works well with stable data hierarchies, and very badly with interfaces, for three concrete reasons.

First: interfaces don't form clean hierarchies. Is a booking panel a panel? What if it also needs the behaviour of a modal and that of a filterable list? With single inheritance you'd have to pick one; with deep hierarchies you end up with BasePanelWithHeaderAndActions, a name that confesses the problem.

Second: inheritance couples from the inside. The subclass depends on internal details of the parent class. Changing the parent breaks children you haven't even opened. In a codebase with two hundred components, that's unmanageable.

Third, and decisive: React already has a better containment relationship. A component doesn't need to be another one to reuse it: it's enough to use it in its JSX. That's composition, and it produces a "has a" relationship instead of an "is a" one.

And there's a technical argument that settles the discussion for good: function components can't be extended. There's no class, no extends, no super. Ever since hooks became the standard way to write React, component inheritance stopped being an available option at all. Classes survive as legacy code (04-03) and for error boundaries (04-05), but even there you extend Component, React's own class, never a component of your own.

children is the special prop you already know from 02-03: it holds everything written between a component's opening and closing tags. It's composition tool number one, and it's used to write generic containers: components that provide structure and styling without knowing what they're going to hold.

CicloUrbano's Panel is exactly that:

Panel knows absolutely nothing about bikes, and that's exactly why it works for anything:

Here's the point worth internalizing: the children slot is what inheritance was trying to achieve with abstract methods, but without coupling anything. The container defines the frame; whoever uses it decides the content.

Two more containers from the same family:

The stopPropagation() on the second onClick is the one from 03-01: without it, a click inside the dialog would bubble up to the backdrop and close the modal. Notice that Modal doesn't know what it contains either: it can wrap a BookingPanel, a BookingForm, or a confirmation message, without changing a single line.

A single children falls short as soon as the container has several zones. The solution isn't to invent conventions about the order of children, but to accept JSX in ordinary props. Each prop of this kind is called a named slot.

And its use in CicloUrbano's catalogue:

There's nothing magic here: a prop can hold JSX exactly the way it holds a number or a string, because JSX is just a JavaScript value. The original Panel was already doing this with footer.

When to pick each option:

A not-so-obvious advantage of named slots: the JSX you pass is created in the parent component, so it can read the parent's state without any trouble. In the example, TypeSelector receives chosenType from App even though it's painted inside AdvancedPanel, which knows nothing about filters. Position in the tree and ownership of the data are two separate things.

Here's the direct replacement for inheritance. When you want a "specific case" of a generic component, don't extend it: write another component that uses it with fixed props.

First, the generic component:

Details that carry over from earlier lessons: the symbol's aria-hidden is the same pattern as StatusBadge (03-06), because a screen reader shouldn't read out "exclamation mark"; and role changes with urgency, alert for what interrupts and status for what merely informs.

Now, the specializations. Not a single inheritance keyword:

Compare the two mental models:

And the practical benefit: when the designer changes how notices look, you touch Notice.jsx and all three update. When the maintenance wording changes, you touch MaintenanceNotice.jsx and nothing else notices.

There's a case plain children doesn't cover: when the container has data the content needs. A container that filters a list knows which items remain, but not how they should be painted.

The classic solution: pass a function as children, which the container calls with the data. It's called a render prop (or children as a function).

Used with bikes:

And the very same container, untouched, with stations:

What's going on, line by line:

• children stops being JSX and becomes a function. JSX accepts any value between braces, including a function; the only thing that changes is that the container calls it instead of painting it.
• children(filtered) is an ordinary JavaScript call. The container decides what data to hand over; the caller decides how it's painted.
• The filtering logic lives in a single place and serves bikes, stations, or bookings alike.
• The text state doesn't get lifted, in direct application of 04-01: no one outside the container needs it.

Important note. Today this problem is almost always better solved with a custom hook: const { text, setText, filtered } = useTextFilter(items, searchField). The logic is reused just the same, but without adding a level to the component tree and without nesting functions inside JSX. You'll see this in Custom Hooks. Render props stay useful when, besides the data, there's also markup to share — the search field and the count, in this example — and they show up in widely used libraries, so it's worth knowing how to read them.

A higher-order component is a function that receives a component and returns another component with added capabilities. It isn't a React API: it's a pattern, just like decorators in other languages.

They're instantly recognizable by their name (with…) and by the double call when exporting.

Keys to reading HOC code:

• The exported component isn't the one you wrote, but the wrapper. That's why in DevTools you see withAuth(OperatorPanel) and not plain OperatorPanel.
• {...props} is the spread from 02-03, and it's mandatory: without it, the wrapper swallows the props and the inner component is left with no data.
• The HOC injects new props (user), which appear "out of nowhere" in the inner component's signature. That's exactly the main criticism: reading OperatorPanel alone, there's no way to tell where user comes from.

The problem gets worse when they pile up:

That stacking produces the wrapper hell mentioned in 02-02: a tree with five layers that paint nothing, props that appear with no visible origin, name collisions between HOCs, and awkward debugging. Hooks replace it with something much flatter:

No wrappers, no injected props, with the origin of every piece of data visible right there on the line. That's why HOCs have fallen out of favour: don't write them in new code, but expect to find them in projects with years of history behind them (Redux's connect(), which you'll see in 07-05, is the most famous HOC in React's history).

Everything above boils down to one sentence worth memorizing:

Compose for the interface; extract functions or hooks for the logic.

Applied as a decision tree:

Two examples already present in CicloUrbano confirm the diagram's extremes: cx() in src/utils/classNames.js and validateBooking() in src/utils/validateBooking.js are stateless logic, which is why they're plain functions, not components or HOCs. No pattern was needed to reuse them: exporting them was enough.

Let's put the pieces together. App looked like this at the end of 04-01, with the whole structure written out by hand:

And here's how it looks composing Layout + AdvancedPanel + MaintenanceNotice:

The resulting tree:

What's been gained, in concrete terms:

• App reads like a table of contents for the screen again, the goal set back in 02-01. The visual structure (header, main, footer) has moved into Layout and won't be repeated in every new screen you add.
• Not a single inheritance. Five components reused, zero extends.
• Notice is the only one that knows about colours, symbols, and ARIA roles for messages; MaintenanceNotice and BookingCreatedNotice only supply their text and their tone.
• Named slots bring the filter closer to what it filters: TypeSelector is painted in the catalogue panel's header, even though its state still lives in App. Position and data ownership are independent things.

• Trying extends MyComponent. It won't compile with function components and gains nothing with classes. If you feel the urge, you're almost always looking for a children container or a configuration-based specialization.
• Forgetting the spread in a HOC. <Component user={user} /> without {...props} leaves the inner component without the props that came in from outside, and the failure shows up as empty data with no error at all.
• Turning children into a function without warning anyone. If FilterableList does children(filtered) and someone passes it ordinary JSX, the error is children is not a function. Document it in the props block and, if the component supports both forms, check typeof children === 'function'.
• Creating a container for every tiny variation. Before writing SmallPanel, LargePanel, and RedPanel, try a variant prop on a single Panel. Specialization is justified when there's genuinely distinct content or behaviour, not just a different CSS class.
• Nesting too many containers. <Layout><Panel><Card><Panel>… six levels deep makes reading just as hard as the wrapper hell we were criticizing. If the tree becomes unreadable, extract a whole screen into its own component.
• Tip: generic component first, specializations later. Write Notice to solve the specific case in front of you, and extract MaintenanceNotice once the second use case shows up. Generalizing from a single case leads to the wrong abstractions.
• Tip: props that receive JSX are named after their zone, not their content. actions, header, and footer describe where the content goes; bookButton would describe what it is, and would tie the container to one specific case.

Exercise 1. Create SummaryCard, a container with named slots and a single free-content zone. Props: title (string), icon (JSX, optional, painted to the left of the title with aria-hidden), children (body), and actions (JSX, optional, at the foot). Then use it twice on CicloUrbano's screen: once for the fleet summary, and once for station est-01.

Exercise 2. Starting from the generic Notice in section 4, create NoResultsNotice, shown when the filter returns no bikes. It must use tone info, the title "No results," text that mentions the filtered type by its readable label, and a "Show all" button that calls an onReset prop. Wire it into App without touching BikeList.

Exercise 3. Turn this HOC into explicit composition. Explain what improves and what's lost.

Solution 1.

The same container serves two pieces of content that have nothing in common, with not a single conditional line inside: that's composition at work.

Solution 2.

BikeList isn't touched: it keeps its own generic empty state for whenever other screens use it, and App decides on a more specific message here because it's the one that knows about the filter. Notice that LABELS is duplicated across two files; if the project grows, the natural home for that constant would be src/data/domain.js.

Solution 3.

What improves: the title stops being frozen at the moment the component was created and can depend on state — a title computed from the result count, for instance; a level disappears from the tree along with an odd name in DevTools; and anyone reading the JSX sees at a glance that a panel wraps the list, without opening another file.

What's lost: if the same panel with the same title were repeated in fifteen places, the HOC would save repeating two lines. The idiomatic answer to that isn't a HOC, but a configuration-based specialization: function CataloguePanel({ children }) { return <Panel title="Catalogue">{children}</Panel>; }, which reads like ordinary JSX and keeps all the flexibility.

React replaces inheritance with composition, and it doesn't lose a single capability for it. children covers single-zone containers (Panel, Modal, Layout); named slots cover the multi-zone ones (header, actions, footer); configuration-based specialization replaces subclasses (MaintenanceNotice built from Notice); render props solve the case where the container supplies data as well as markup, though today they usually give way to a custom hook; and higher-order components are read but not written, except to maintain existing code. The rule that ties all of this together is a single one: compose for the interface, extract functions or hooks for the logic.

CicloUrbano's catalogue screen has come out recomposed as Layout + AdvancedPanel + content, with every notice coming out of one generic Notice, and App reads like a table of contents again.

One thing remains, something the last two lessons have brushed against without tackling: components are born, change, and die. A Modal that opens and closes, an activity panel that needs a timer while it's on screen and must cancel it when it disappears. That life has phases, and for years it was managed with class components' lifecycle methods, which still populate real codebases today. The next lesson is React Lifecycle Methods, where you'll learn to read them, understand what problem they solved, and translate them into the mental model modern React uses.