You've already written several components whose return contains something that looks like HTML but lives inside a JavaScript file. That's JSX, and it deserves a lesson of its own because almost every stumble in the first weeks with React comes from assuming JSX is HTML. It isn't: it's JavaScript syntax disguised as HTML. In this lesson you'll demystify JSX by seeing what it actually turns into, learn its exact rules, and master curly-brace interpolation, which is what turns a fixed-text card into a card that shows real CicloUrbano data.

1. What JSX is and what it compiles into
2. Rule 1: a single root element (and fragments)
3. Rule 2: attributes with JavaScript names
4. Rule 3: every tag must close
5. Curly-brace interpolation: expressions yes, statements no
6. Dynamic attributes
7. Inline styles with an object
8. Comments inside JSX
9. What React renders and what it doesn't: null, undefined, false, and the case of 0
10. HTML vs JSX comparison table

JSX (JavaScript XML) is a syntax extension for JavaScript. Browsers don't understand it: before it reaches the browser, a build tool (in our case Vite, via @vitejs/plugin-react) translates it into plain JavaScript.

The best way to stop being intimidated by it is to see the translation. This component:

Conceptually, it turns into this:

React.createElement always takes three things: the element type, an object with its properties, and its children. And it returns a plain JavaScript object, something like:

Three very important conclusions follow from this:

• JSX is syntactic sugar. You could write an entire React app without JSX, calling createElement by hand. Nobody does, because it's unreadable, but it's worth knowing there's no magic involved.
• JSX produces objects, not HTML. What your component returns isn't a text string or a DOM node: it's a lightweight object describing the interface. That object is what React compares to figure out what to update, the topic of the next lesson.
• A JSX element is a JavaScript value. You can store it in a variable, pass it as an argument, or return it from a function:

Note on React 19: since the "new JSX transform" (React 17 onward), the compiler doesn't literally generate React.createElement, but an internal _jsx function that it imports automatically. That's why you no longer need to write import React from 'react' in every file, as older tutorials required. The idea is identical; only the implementation detail changes.

A function can only return one value. Since JSX translates into a call to createElement, a component can only return one root element.

Vite rejects it with Adjacent JSX elements must be wrapped in an enclosing tag.

The obvious fix is to wrap it in a container:

But sometimes you don't want an extra container: it would add a useless div to the DOM that could break a grid, a flex layout, or the semantics of a table. That's what fragments are for: they group elements without producing any tag:

<>...</> is the fragment's shorthand syntax. There's also the long form, <Fragment>...</Fragment>, needed only when the fragment must carry a key (something that happens when iterating over lists, in lesson 03-03):

Rule of thumb: if the container adds meaning (<article>, <section>, <ul>), use it. If it would only be there to keep React happy, use a fragment.

In JSX, attributes are actually properties of a JavaScript object. That forces two adjustments relative to HTML.

Reserved words. class and for are reserved words in the language, so they get renamed:

camelCase. Multi-word attributes are written in camelCase, because that's how the equivalent DOM properties are named:

There are two exceptions worth remembering because they tend to surprise people: data-* and aria-* attributes keep their hyphens as is, since they aren't DOM properties but genuine attributes.

Good news: if you get it wrong, React usually warns you in the console with a very clear message like "Invalid DOM property class. Did you mean className?". Read them, don't ignore them.

JSX inherits XML's strictness: there's no such thing as an unclosed tag. In HTML you can write <br> or <img src="..."> and the browser tolerates it; in JSX it's a syntax error.

The same applies to your own components: <BikeCard />, not <BikeCard>. And tags with content must always be closed, in the right order; JSX won't forgive a <p> without a </p> or crossed nesting.

Here's JSX's real power. Curly braces {} open a window back into JavaScript: whatever you put inside gets evaluated, and the result is inserted into the interface.

Compare this to the previous lesson's version: the text is no longer hand-written, it's computed from data. It's the same component, but now it's dynamic.

Any JavaScript expression fits inside the curly braces:

The rule governing all of this: expressions yes, statements no. An expression produces a value; a statement performs an action. Since the content inside the braces ends up as an argument to a function call, it has to produce a value.

This explains why conditional rendering in React is written with the ternary operator or with &&, and why lists are rendered with .map() instead of a for loop: they're the expression versions of those constructs. Both topics get their own lesson: Conditional Rendering and Lists and Keys. Here you just need to understand why.

If a calculation is too long to fit in a readable expression, the fix is to pull it out before the return, where you can write as many statements as you like:

This pattern — compute above, display below — keeps JSX clean, and it's one of the signs of well-written React code.

Curly braces also work in attributes. The difference is subtle but fundamental:

A very common mistake is mixing the two: src="{logoPath}" passes the literal string "{logoPath}", not the value. Quotes or braces, never both.

Full example applied to CicloUrbano, building dynamic CSS classes:

Details worth noting:

• className with a template string. It produces "bike-card bike-card--electrica". It's the usual pattern for combining a base class with a modifier.
• disabled={!available}. Boolean attributes take an actual boolean, not a string. If the value is false, React omits the attribute from the generated HTML. Watch out for disabled="false": since every non-empty string is true in JavaScript, the button would end up disabled!
• Dynamic aria-label. Accessibility attributes benefit enormously from interpolation: each button describes exactly which bike it belongs to.
• data-bike-id keeps its hyphens, as we saw.

In HTML, style takes a CSS text string. In JSX it takes a JavaScript object:

That double set of braces confuses everyone the first time, so separate them mentally:

• The outer braces are JSX interpolation: "a JavaScript expression goes here."
• The inner braces are a JavaScript object literal.

It's exactly the same as writing:

Rules for that object:

Properties are written in camelCase and values are strings, except for numeric values on properties that accept pixels, where React adds px automatically. Watch out for that convenience: lineHeight: 2 means "2 times", not "2 pixels", because line-height is unitless.

Applied example, with a computed status color:

When to use inline styles: only for genuinely dynamic values that depend on data (a computed color, a progress-bar width). For everything else, use stylesheets: inline styles don't support :hover, media queries, or pseudo-elements, and they aren't cached. The full styling strategies are covered in Styling Components.

JavaScript's // and /* */ comments don't work inside JSX: they'd end up rendered as text. You need to wrap them in braces:

In attributes, however, you comment as in plain JavaScript, because you're already inside an expression there:

Most editors do the right thing automatically with Ctrl+/ if they have JSX support.

React silently ignores certain values inside curly braces. Knowing which ones avoids unpleasant surprises.

The fact that null, undefined, and false don't render is a very useful feature: it lets you write "render this only if something is true" without any special structure.

And here's the trap with 0. The && operator returns the left-hand operand when it's falsy. If that operand is 0, React does render it, because 0 is a perfectly valid number:

This "ghost zero" is one of the most commonly reported beginner mistakes in React. The rule to avoid it: the left side of && must always be a boolean, never a number or a string.

About the object error: {bike} fails because React doesn't know how to render an object. You need to access its properties ({bike.model}) or, if you're debugging, convert it to text:

• Writing class instead of className. The warning shows up in the console and the styles don't apply. It's so common that it's worth automating: a well-configured ESLint flags it as you type.
• Mixing quotes and braces: src="{path}". It passes the literal string. Either quotes for fixed values, or braces for expressions.
• Trying to put an if or a for inside the braces. They're statements. Pull them out before the return, or use their expression equivalents (? :, &&, .map()).
• Forgetting to self-close <br>, <img>, <input>, or <hr>. Immediate syntax error; Vite's message points precisely to the line.
• The "ghost zero" with &&. Repeat it until it sticks: the left side of && must be a boolean. freeDocks > 0 && ..., never freeDocks && ....
• Rendering an object: {bike} instead of {bike.model}. The message Objects are not valid as a React child is literal and tells you exactly what's wrong.
• A single pair of braces in style. style={{ color: 'red' }} needs two: interpolation plus object.
• Tip: when you're unsure what a complicated piece of JSX does, mentally translate it to createElement. If the translation doesn't make sense as a function call, the JSX won't make sense either.
• Tip: if a component's JSX takes up more than one screen, it's not a JSX problem but a design one: that component is probably doing too much and should be split up. You'll work on this in Module 2.

Translate the following HTML for a CicloUrbano station card into correct JSX. It should be a complete, ready-to-use StationCard component, with the three syntax fixes it needs.

Write a BookingSummary component that, using these constants declared inside the component, shows the model, the hours, the total price with two decimal places, and a notice only when the booking exceeds 4 hours. Everything must come from interpolated expressions, with no duplicated fixed text.

The following component has a visual bug: when freeDocks is 0, a stray 0 appears on screen instead of nothing showing. Explain exactly why this happens and propose two different solutions.

Solution 1.

The fixes: class → className; style as a string → an object with borderLeft in camelCase and the compound value in quotes; <hr> → <hr /> and the self-closed <input>; for → htmlFor; readonly → readOnly.

One extra detail: React will warn in the console that an input with a fixed value and no change handler is read-only. Here that's intentional, which is why it has readOnly; editable fields are covered in Forms and Controlled Components.

Solution 2.

With this data it shows "Total: €24.00" and the notice, because 6 is greater than 4. Notice that the && condition is a comparison, so it's already a boolean: there's no risk of a ghost zero.

Solution 3.

Why it happens: the && operator evaluates its left operand; if it's falsy, it returns that same value instead of a boolean. Since freeDocks is 0, the whole expression returns 0. And 0 is a valid number for React, which renders it as is. Only null, undefined, true, and false are silently omitted.

Solution A — turn the condition into an explicit boolean:

Solution B — use a ternary, which also covers the opposite case:

A third approach, somewhat less readable but also valid, is to force the boolean with double negation: {!!station.freeDocks && ...}. Always prefer the explicit comparison: it communicates the intent better.

JSX isn't HTML: it's syntax that transforms into function calls producing JavaScript objects describing the interface. Every one of its rules follows from that nature: a single root element (or a fragment <>...</>), attributes named after DOM properties (className, htmlFor, camelCase), mandatory closing of every tag, and curly braces {} to interpolate expressions — never statements. You now know how to build dynamic attributes, apply inline styles with an object, comment with {/* */}, and avoid the 0 trap with &&.

With that, you can already describe any interface. One essential question remains: what does React actually do with those objects your components return? How does it go from an in-memory description to pixels on the screen, and how does it manage to update it without repainting everything? That's what you'll see in How React Renders: Virtual DOM and Reconciliation, the lesson that closes out this first module.