You closed out Module 1 knowing how React turns your functions into a screen: JSX compiles into objects, those objects form a tree, and reconciliation decides what to touch in the real DOM. Now it's time to move up a level and look at the problem from a design angle, not from the engine's. A component isn't just "a function that returns JSX": it's your application's unit of design, the box where you decide which markup, which logic, and which style live together. This lesson is about the most frequent and most consequential decision you'll make in React: where to draw the dividing lines. We'll start from the real sketch of CicloUrbano's catalogue screen, break it down into components with judgment, draw its hierarchy, and organize the files so that, twenty components from now, you're still finding what you're looking for.

1. What a component actually encapsulates
2. From sketch to components: CicloUrbano's catalogue screen
3. Three criteria for deciding a component's boundaries
4. The component tree: parent-child relationships
5. Presentation components and container components
6. File organization and naming conventions
7. Default export vs named export
8. Composing: assembling the full screen
9. The limitation we're still carrying: the data is still fixed

In Module 1 you wrote Welcome and BikeCard as functions that return JSX. That's the mechanics. The underlying idea is something else: a component groups the three things that define a piece of interface into a single place.

For years, best practice in web development was exactly the opposite: HTML in one file, CSS in another, JavaScript in a third. React proposes separating by functional concern instead of by technology. The reasoning is simple: when someone asks you to "change how a bike looks in the catalogue," you don't touch "the CSS" or "the JavaScript," you touch the bike card. Having everything that defines the card in view in a single file is what makes the change fast and safe.

This has three practical consequences worth internalizing right away:

• A component is replaceable. If BikeCard honors its contract, you can rewrite it entirely without the rest of the application ever knowing.
• A component is reusable. The same component works in the catalogue, in a station's detail view, and on the bookings screen.
• A component is reasonable in isolation. You can understand what BikeCard does without reading App.jsx. When that stops being true, it's almost always because the component is doing too much.

Here's the sketch of the screen we're going to build over the next few modules: CicloUrbano's bike catalogue.

The method for breaking it apart is always the same: draw a rectangle around every zone that has a name of its own and check whether that name describes a responsibility. Applying it yields five components:

Notice two decisions that aren't obvious:

• BikeList exists even though right now it looks like a plain container. We give it its own identity because later it will host the type and status filters and the "no results" message. It's the zone that's going to grow, and already having its own box keeps that growth from spilling over into App.
• StatusBadge exists even though it's just a <span>. The badge will also show up in the station detail view and in the bookings list, always with the same color rules. A two-line component used in three places is more than justified.

There's no mechanical rule, but there are three criteria that, applied in this order, resolve almost every case.

You should be able to describe a component in one sentence without the word "and."

• ✅ "BikeCard shows the data for one bike."
• ❌ "Catalogue shows the header and filters the bikes and paints the cards and manages the footer."

When the description needs conjunctions, you have a candidate for splitting. Watch out for the opposite false positive: splitting so much that every component is an HTML tag in disguise. A <SectionTitle> that just returns <h2> doesn't add anything.

If a piece appears — or is going to appear — in more than one place with the same look and the same rules, it's a component. This criterion is what justifies StatusBadge: the mapping from disponible to green and mantenimiento to red is a decision we want written exactly once. If it were copied across three screens, the day the palette changes you'd have to remember all three spots.

Watch out for the reverse mistake: don't create a reusable component before you have the second use case. Designing for imaginary reuse produces components with twisted contracts that end up not fitting the second real case.

There's no magic number of lines, but there are reliable signs a component has outgrown its size:

And one sign that you've split things up too much: to understand a simple screen you have to open seven files and jump between them. Excessive fragmentation is technical debt too.

When you study state (lesson Component State) a very powerful additional criterion will show up: what changes together, lives together. Parts of the interface that update at the same time usually belong to the same component. For now, stick with the first three.

When a component uses another one inside its JSX, a parent → child relationship is established. The set of all those relationships forms the component tree, which is your application's mental map.

Three important clarifications about this diagram:

• Parent and child isn't inheritance. BikeCard doesn't inherit anything from BikeList; it just appears inside its JSX. React doesn't use inheritance between components, it uses composition, and that contrast is covered in depth in Composition vs Inheritance.
• The same component appears as many times as it's used. There are three BikeCard nodes in the tree because there are three bikes on screen. Each one is an independent instance: they share the code, not the data or the state.
• Information flows down the tree. Data flow in React is unidirectional: from parent to child. That's exactly the path props will travel, in the lesson Props.

This tree is also what you'll see in the Components tab of React DevTools, the extension you installed in lesson 01-02. Keep it open while you build: comparing the tree you sketched with the one React shows is the fastest way to catch that your mental structure and your code have drifted apart.

Over time you'll notice your components naturally fall into two families.

The usefulness of this distinction is practical, not dogmatic: push logic upward and keep the leaves of the tree dumb. A BikeCard that doesn't know where its data comes from can be dropped into any screen, tested in two lines, and redesigned without fear.

An honest nuance: in the React community this separation used to be applied very strictly (people talked about "dumb" and "smart" components). With hooks, the line has become blurrier, and today it's considered a guideline, not a law. Even so, asking yourself "does this paint, or does this decide?" remains one of the best ways to clarify a confusing component.

With five components, any organization works. With fifty, it doesn't. These are the conventions we'll use throughout the course.

The rules, and the reason for each one:

On folder structure there are two schools: by type (components/, data/, hooks/) and by feature (catalogue/, bookings/, stations/). For a small application like ours, the first is simpler, and it's the one we'll follow. In Module 11, once CicloUrbano has several sections, we'll revisit whether it's worth migrating to the second.

Every component file has to export something so other files can import it. There are two ways, and it's worth understanding the difference clearly.

There can be at most one default export per file. It's the dominant convention in React for "the main component of this file."

There can be as many as you like per file. It's the natural form when a module exposes several things, like our domain.js.

Course convention: default export for components (one component per file) and named export for data and helper functions. It's the most widespread mix in Vite projects, and what you'll see in most real-world code.

Let's write the new components and assemble the screen. Remember: the data is still hand-written inside each component, just like in lesson 01-03.

Two lines, and yet it's a legitimate component: it concentrates the decision of how a status gets represented. Once it receives the status from outside in the lesson Props, the status--disponible class will start being computed, and this component will be the only place in the project where that rule exists.

Something new happens here: a component that uses another component. Header imports Welcome exactly the way App used to import it. There's no special hierarchy: any component can use any other component it imports.

Since Welcome now lives inside a <header>, its own one needs to be removed so as not to nest two headers, which would be semantically incorrect:

This adjustment illustrates something you'll see constantly: component boundaries get renegotiated. Welcome started out as the entire header because there was nothing else; now that navigation has appeared, its role shrinks down to the welcome message, and Header takes over the frame. Refactoring boundaries is normal work, not a sign you got it wrong the first time.

This component is a container in the making: today it only groups things, but it's the box already prepared to receive the filters from Module 3.

Notice the bike-card--urbana class: the type variant we established in CicloUrbano's design. In the lesson Styling Components it will stop being hand-written and will start being built from the type.

Look at what's happened to App: it's down to three lines of JSX that read like a table of contents for the screen. That's the goal. A root component that reads like an outline is the best sign that the decomposition is well done; a two-hundred-line App.jsx is the opposite sign.

Add the styles for the new pieces to src/index.css:

Open the browser and you'll see the mockup's screen… with three identical bikes, all three "Classic Urban, disponible, Main Square." The structure is correct; the data isn't.

The cause is the same as in lesson 01-03: each component carries its data written inside it. And that's exactly the opposite of what we want, because it breaks the reusability criterion: a component whose data lives inside it can only ever show that data.

The missing piece is props, and that's the content of the lesson Props: Passing Data to Components. There, BikeCard will receive a bike from domain.js, and the three cards will finally show bici-001, bici-002, and bici-003. Rendering the full array without writing out each card by hand comes a bit later, in Lists and Keys.

• Creating components "just in case." Extracting SectionTitle, GrayParagraph, or FlexContainer before you have a real problem only adds indirection. Extract when the component has an obvious domain name, or when the second use shows up.
• Letting App.jsx grow unchecked. It's the application's natural dumping ground. If App starts containing detailed markup instead of a list of sections, extract that markup into a component.
• Defining a component inside another one. Writing function BikeCard() {…} inside the body of BikeList compiles, but a new function gets created on every render; for the reconciliation you studied in 01-05, that's a different type, so it destroys and recreates the entire subtree and loses its state. Always define components at the top level of the module.
• Naming by appearance instead of by role. GreenBox stops making sense the day the design changes to blue. StatusBadge stays correct no matter what happens to the palette.
• Confusing the component tree with the DOM tree. Header doesn't generate a <Header> tag: it generates whatever's in its return — which happens to include a real <header> element, but doesn't have to. A component can produce many nodes, one, or none.
• Tip: sketch the tree before writing code. Five minutes with a sketch and a marker save an afternoon of reorganizing. And compare it afterward with the Components tab in React DevTools.
• Tip: apply the name test. If you can't give a component a short, descriptive name, the problem isn't the name: it's its boundaries.

CicloUrbano's application needs a station detail screen. Here's the sketch:

Identify the components you'd use, indicate which ones already exist and which would need to be created, and classify each one as presentation or container. Justify each decision with one of the three criteria from section 3.

A colleague wrote this component. Spot the design problems and propose a better decomposition, without writing the full code: the resulting tree plus the name and responsibility of each piece is enough.

Create the FleetSummary component in src/components/FleetSummary.jsx. It should show, inside a <section className="fleet-summary">, an <h2> with the text "Fleet summary" and three lines with CicloUrbano's fleet totals according to domain.js: total bikes, available, and unavailable. Write the numbers by hand (we don't yet know how to compute them from the data) and place it in App.jsx between the header and the list. Then draw the updated component tree.

Solution 1.

What matters about this exercise is that four of the six components already existed. That's what you gain with well-drawn boundaries: the second screen costs far less than the first.

Solution 2.

Design problems:

1. No single responsibility. Everything acts as header, navigation, catalogue, card, and footer all at once; its description would need four "and"s.
2. Zero reuse. The card's markup is literally duplicated, and so is the status badge's. Any design change has to be applied twice.
3. Useless name. Everything doesn't describe any responsibility, which is the classic symptom of badly drawn boundaries.
4. Non-semantic markup. <div> for the cards and for the navigation, instead of <article> and <nav>.

Proposed decomposition:

Solution 3.

Updated tree:

The numbers "5, 3, 2" come from counting domain.js by hand, and that's exactly the problem: if a new bike gets added tomorrow, the summary will lie. Deriving those totals from the data is the subject of an upcoming lesson.

A component is React's unit of design: it encapsulates markup, logic, and style for a piece of interface, and its value depends above all on where you draw its boundaries. Now you have a method for drawing them: start from the sketch, circle the zones that have a name of their own, and validate each candidate against three criteria — single responsibility, reuse, and manageable size — avoiding both the component that does everything and fragmentation into trivial pieces.

You've turned CicloUrbano's catalogue sketch into a real component tree: App assembles Header, BikeList, and Footer; Header contains Welcome; BikeList contains BikeCard, and that in turn contains StatusBadge. You know how to tell presentation components apart from container components and how to use that distinction to push logic upward and keep the leaves reusable. And you've settled the conventions the whole course will follow: one component per file in src/components/, PascalCase, .jsx extension, default export for components and named export for data.

You've also hit the ceiling we're still bumping against: the structure is correct, but the three cards are identical, because the data is still written inside the components.

Before breaking through that ceiling, there's a mandatory stop. Everything you've written so far consists of function components, but in any React project with a few years behind it you'll run into components written with classes: a different syntax, with this, render(), and constructor. You won't be writing new code that way, but you do need to know how to read it. That's the subject of the next lesson: Function vs Class Components.