CicloUrbano already responds to clicks, but it always paints the same thing: a bike under maintenance shows a "Book" button that shouldn't be there, and a catalogue with no results stays blank without explaining why. The interface needs to decide, and deciding is exactly what conditional rendering does. React has no special syntax for this: since JSX is JavaScript, you use the language's own tools — if, the ternary operator, &&, ??, objects and switch — each with its own strengths and its own breaking point. In this lesson you'll see all six techniques applied to the same case, so you can genuinely compare them, learn when each one is the right fit, and defuse a classic trap in the && operator that can slip a stray 0 into the middle of your interface.

1. The principle: interface = f(state)
2. Technique 1: if/else before the return
3. Technique 2: the ternary operator inside JSX
4. Technique 3: && to show or not show
5. Technique 4: ?? for absent values
6. Technique 5: a lookup object
7. Technique 6: switch in a helper function
8. Comparison table: when to use each one
9. Early return: rendering nothing
10. The && trap with numbers and strings
11. Named conditional components
12. CicloUrbano: cards that adapt to status

In the course's first lesson we defined React with a formula: the interface is a function of the data. Conditional rendering is the direct consequence of that idea. You don't manipulate the DOM to hide a button; you describe what should appear for each combination of data, and you let React work out the difference.

Compare it with what you'd do without React:

The difference isn't just length. In the imperative version, the button always exists in the DOM and it's up to you to hide it; if you add a third status tomorrow, you have to remember to touch that code. In the declarative version, the button doesn't exist when it shouldn't, and the condition is written right where the markup is read.

And an idea worth fixing in your mind now: in React, not rendering something is expressed by returning a value that doesn't render. As you saw in lesson 01-04, null, undefined, false and true produce nothing on screen. Every technique in this lesson rests on that property.

The most readable form when the condition affects a large part of the result: you decide beforehand, store it in a variable, and the JSX stays clean.

Important points:

• let message holds a JSX element. Remember from lesson 01-04 that a JSX element is a plain JavaScript object: it can be stored in a variable, put in an array, or passed as a prop.
• The if sits outside the return. Only expressions fit inside JSX, and if is a statement. Writing {if (x) ...} inside the braces is a syntax error.
• The final JSX reads at a glance. All the decision logic is up top, grouped together, with the markup below.

This technique is best when the branches are long, or when other things need calculating along the way (a piece of text, a class, a derived value).

The ternary operator condition ? valueIfTrue : valueIfFalse is an expression, so it fits inside the braces. It's the tool for choosing between two concrete alternatives.

It works just as well with full elements, not just text:

Notice the parentheses wrapping each branch when the JSX spans several lines: they aren't syntactically required, but they avoid automatic-semicolon-insertion mistakes and make the block far more readable.

It's also used constantly to pick classes or attributes, not just content:

Its limit is nesting. A ternary inside another one is still readable; a third level isn't:

Once you reach that point, the answer isn't "format it better" — it's switching technique (sections 6, 7 and 11).

When the alternative is "this or nothing", the ternary with : null is overkill, and the && operator is more direct.

Exactly how it works, because this isn't React magic but plain JavaScript:

1. && evaluates the left-hand operand.
2. If it's falsy, it returns that operand and never evaluates the right-hand side.
3. If it's truthy, it returns the right-hand operand.

So when the condition is false, the whole expression is false, and React doesn't render booleans. When it's true, the expression is the JSX element, and React renders it.

Typical cases:

It's the single most used technique of all, and also the one that causes the most headaches, for one very specific reason you'll see in section 10. Keep this rule in mind: the left side of && must always be a boolean.

The nullish coalescing operator (??) returns the right-hand operand only when the left-hand one is null or undefined. It's the perfect complement for optional data.

The difference from || is subtle but decisive, and in an app with numbers and text it shows up constantly:

The example that makes it obvious, with CicloUrbano data:

Practical rule: use ?? for values that might be missing, and || only when you genuinely want to treat 0 and the empty string as "absent".

When there are three or more enumerable cases, the cleanest solution isn't a chain of ifs or a nested ternary: it's an object that maps each value to what should render.

What this version gains over the one from 02-05:

• The visible text is no longer the raw technical value. Before it literally rendered mantenimiento; now it renders "In maintenance", which is what a person can understand.
• Adding a fourth status means adding one line to the object. Neither the JSX nor the logic needs touching.
• ?? UNKNOWN_STATUS covers the unexpected case. If an unaccounted-for status ever arrives, the badge says so instead of staying blank or breaking.
• The map lives outside the component. Declaring it inside would recreate it on every render for no reason, and keeping it outside also makes clear it's a domain constant, not component data.

The same pattern works for choosing entire components, not just text:

There's the capital letter rule from lesson 01-03, in its subtlest form: const Notice = NOTICES[...] must be called Notice, not notice, because JSX treats lowercase tags as DOM elements. <notice /> would try to create a non-existent HTML tag.

switch is a statement, so it doesn't fit inside JSX. But it does fit inside a helper function that returns JSX and gets called from the markup.

Two observations:

• The function is called with parentheses ({renderMessage()}), because we want its result now, not a reference. It's the opposite of what you did with event handlers in 03-01: there you wanted the function itself, here you want the JSX it returns.
• The default case isn't optional in practice. Without it, an unexpected value makes the function return undefined and nothing renders — a silent failure that's hard to catch.

When should you reach for switch instead of a lookup object? When each branch needs logic, not just a value: computing something, composing several elements, checking another prop.

The natural progression when writing real code: you start with &&, move to a ternary once a second alternative appears, and jump to an object or named components once you hit the third case. The sign that you've outgrown a technique is having to count parentheses to understand your own JSX.

A component can decide it shouldn't render at all. The idiomatic way is to return null as early as possible.

Details worth understanding:

• return null isn't an error: it's a valid return value meaning "I produce no markup".
• The component keeps mounting and running. Returning null doesn't unmount it: React keeps it in the tree, with its state intact, simply with no DOM nodes. This distinction will matter once you reach effects in Module 5.
• It's also useful as a guard against missing data, and that's its most common use:

This pattern, called a guard clause, keeps the whole component body from being wrapped in one giant if and wipes out "Cannot read properties of undefined" errors in one stroke.

Lesson 01-04 introduced the "phantom zero" with freeDocks. Now that && is your main tool, it's time to see it in the scenario where it bites hardest: counting the items in a collection.

Step by step, with bikes = []:

1. bikes.length is 0.
2. 0 is falsy, so && returns 0 without evaluating the right-hand side.
3. The whole expression is 0… and 0 is a number React does render.
4. Result: where there should be nothing, a baffling 0 shows up instead.

It's exactly what happens with false, except false doesn't render and 0 does. The three correct fixes:

The same problem, with some nuance, shows up with strings:

Here the empty string is falsy, the expression is '', and React doesn't render empty strings, so visually nothing bad happens. But the code is still fragile: if that variable can ever hold '0' or a number, the bug appears. Always write the full condition:

Definitive rule: on the left of &&, always a comparison. x > 0, x !== '', Boolean(x), x === 'disponible'. Never a raw value.

There's a technique that isn't an operator, but a design decision: when the conditional gets complicated, extract each branch into a component with a name that explains what it is.

Compare. The nested-ternary version:

No one wants to maintain that. The named-components version:

What was gained:

This is the same boundary-drawing criterion you learned in lesson 02-01: if a conditional branch has its own name in the team's conversation, it deserves to be a component.

Let's now apply what we've learned to the app. BikeCard will decide three things: whether to show the "Book" button, whether to show the workshop notice, and how to describe the price.

With the data from domain.js, the result per bike is:

A catalogue that finds nothing and stays blank is a classic design flaw: the person using it can't tell whether the app is loading, has broken, or genuinely has no results. The fix is an explicit empty state.

Yes, writing the same card three times with an && each time is tedious, and that ugliness is still deliberate: it's the last warning before the refactor. In the next lesson, map wipes out the three props and the three repetitions in one stroke.

The card's full decision flow, summarized:

• Writing if inside JSX. {if (x) ...} is a syntax error: only expressions fit inside the braces. Use a ternary, &&, or move the if before the return.
• The phantom 0 with &&. {list.length && <p>…</p>} renders a 0 when the list is empty. Always write a comparison: list.length > 0 && ….
• Using || with numbers. {docks || 'no data'} treats 0 as absence. Use ?? unless you genuinely want the opposite.
• Ternaries nested three levels or more. They become impossible to read and to change. Switch to a lookup object or named components.
• Forgetting the default in a switch. An unexpected value returns undefined and nothing renders, with no visible error at all.
• Naming a component pulled from an object in lowercase. const notice = NOTICES[status] and then <notice /> creates a non-existent HTML tag. It has to be const Notice = … and <Notice />.
• Believing return null unmounts the component. It doesn't: the component stays in the tree with its state. To actually unmount it, the parent has to stop rendering it.
• Hiding with CSS what should never render. style={{ display: 'none' }} leaves the markup in the DOM, with its cost and still accessible to screen readers. If it shouldn't be there, don't render it.
• Defining the lookup object inside the component. It gets recreated on every render for no reason. Declare it as a constant outside.
• Tip: always think about the empty case and the error case. "No results", "loading", "missing data". Interfaces break at the edges, not in the happy path.
• Tip: extract the condition into a named variable. const available = bike.status === 'disponible' reads far better inside JSX than repeating the full comparison three times.
• Tip: if the markup of two branches is nearly identical, don't duplicate the JSX. Condition only what changes (a class, a text, an attribute).

This component has four conditional-rendering bugs. Find them, explain the symptom of each one, and rewrite it with the right techniques.

Create the BookingPanel component (src/components/BookingPanel.jsx), building on the one you wrote in 02-04. It should:

• Receive bike (which can be undefined) and hours with a default value of 1.
• If there's no bike, show "Select a bike from the catalogue." via an early return.
• If the bike isn't available, show a notice explaining why, different depending on whether it's alquilada or mantenimiento, using a lookup object.
• If it's available, show the model, the hours, the calculated total price, and a "Confirm booking" button.
• Also show, only when the total exceeds €10, a notice reading "Long booking: email confirmation required."

For each CicloUrbano situation, say which technique of the six you'd use and write the corresponding line or block. Justify the choice in one sentence.

1. Show an "Electric" badge only if bike.type === 'electrica'.
2. Paint a station's icon based on its district: Downtown, North or Riverside, with a different icon for each.
3. Show "Loading…" while bikes is undefined, and the catalogue once it has arrived.
4. Show the user's email, or "No email on file" if it's null.
5. Choose between a "Book" button and a "Cancel booking" button, depending on whether the user already has an active booking.

Solution 1.

The four bugs:

Extracting parked and free into named variables also removes the repeated calculation and keeps the conditions readable.

Solution 2.

The two early returns keep the main body free of nesting: by the time the code reaches the last part, we already know for certain there's a bike and that it's available. And total, formattedTotal and available are derived values, not state.

Solution 3.

In case 2, the ?? '📍' guards against a new district that doesn't have an icon assigned yet: the interface shows a generic marker instead of an empty gap.

Conditional rendering in React adds no new syntax: it leans on the JavaScript you already know and combines it with one key property of JSX, that null, undefined, false and true render no markup. On that foundation you've seen six techniques and, above all, when to use each one: if/else before the return for long branches; the ternary for choosing between two concrete alternatives, with nesting as its clear limit; && for show-or-nothing, the most frequent case of all; ?? for data that might be missing, without the problem || has with 0; the lookup object for enumerable sets of statuses, flat and extendable with one line; and the helper switch when each branch needs its own logic. On top of that, two structural tools: the early return with return null or a guard clause, and extracting branches into named components once the conditional starts requiring you to count parentheses.

You've also closed the && trap left open in the JSX lesson, and now you know it in its most dangerous form: {list.length && …} renders a 0 on screen when the list is empty. The rule is non-negotiable: on the left of &&, always a comparison.

CicloUrbano feels it: StatusBadge translates the technical status into readable text through an extendable map, BikeCard hides the "Book" button on bikes that shouldn't offer it and flags the ones in the workshop, and the catalogue now has an empty state that explains what happened instead of leaving a blank gap.

But the list is still written card by card, with three numbered props and three nearly identical && blocks. It's the last ugly leftover from Module 2, and also the debt we've been carrying since the reconciliation lesson, where we promised to explain what key is really for. Both get settled at once in Lists and Keys, where a single line with map will replace all of that scaffolding.