In the module's first lesson we said a component encapsulates three things: markup, logic, and style. The first two are already settled: markup lives in the JSX and logic in the function body. Style, on the other hand, is still piled up in a single src/index.css that keeps growing unchecked, where nothing stops two different people from defining a .card class with incompatible rules three months from now. React imposes no single solution for this: it offers you several strategies and expects you to choose with judgment. In this lesson you'll see all four used in practice, all applied to the same component — BikeCard — so you can really compare them, you'll learn to build dynamic class names from a bike's status, you'll tidy up CicloUrbano's palette with CSS variables, and you'll adopt the strategy the project will use from here on.

1. The problem: style is part of the component too
2. Strategy 1: imported global CSS
3. Strategy 2: inline styles with objects
4. Strategy 3: CSS Modules with Vite
5. Strategy 4: CSS-in-JS and utility frameworks
6. Conditional classes based on a bike's status
7. CSS variables for CicloUrbano's palette
8. Final comparison and the course's decision

Today BikeCard is incomplete as a unit: its markup and logic live in BikeCard.jsx, but its style rules sit a hundred lines away, in a file it shares with everything else. That creates four concrete problems:

React doesn't solve this for you, but it does give you the missing ingredient: the component can decide its classes at run time, because className is a JavaScript expression like any other.

The four existing strategies can be ordered by where the style lives:

This is what you've used so far: write plain CSS and import it.

Vite also lets you import a .css from the component itself, which improves the organization a little:

But watch out: this doesn't make it local. Vite collects every imported .css file and bundles them into the page's stylesheet. The file is closer to the component, yes, but its classes are still global.

Imagine that two months from now someone adds a bookings screen with its own stylesheet:

That file gets imported and, without anyone intending it, the catalogue cards lose their border and max width. There's no error, no warning: just a broken layout that shows up when you navigate in a certain order. Debugging it takes half an afternoon.

The traditional mitigations exist and work halfway:

• BEM-style naming conventions: .bike-card__title, .bike-card--urbana. They cut the risk a lot, but depend on the whole team's discipline, forever.
• Per-component prefixes: the same idea, with the same fragility.

When to use it: for what must be global. Resets (box-sizing), base typography, body colors, and above all the palette's CSS variables, as you'll see in section 7.

React lets you pass a JavaScript object to the style attribute:

Remember from lesson 01-04 the rules for this object:

• Double braces: the outer ones open the JSX expression, the inner ones are the object literal.
• camelCase properties: borderRadius, not border-radius.
• Values as strings, units included. Numbers without a unit are read as pixels: padding: 16 means 16px.

This is its legitimate case, and it's real. A station's occupancy bar, whose width depends on the data, can't be expressed with a CSS class, because the percentage is only known at run time:

Here the division of labor is right: the class supplies everything static (colors, height, borders) and the inline style supplies the one value that depends on the data.

When to use it: only for dynamic values that CSS can't know — percentage widths, positions, computed transforms — and always combined with a class that supplies the rest. Never as the main strategy.

A CSS Module is an ordinary CSS file whose name ends in .module.css. Vite detects it automatically — no configuration needed — and does two things: it renames every class so it's unique across the whole application, and it hands you back an object that translates your names into the generated ones.

Notice the names: .card, .title, .meta. Short and generic, because the local scope makes a prefix unnecessary. There's no risk of them colliding with the .card of another component.

import styles from './BikeCard.module.css' doesn't import text: it imports an object that Vite generates while processing the file.

And the HTML that reaches the browser:

That suffix is computed from the file's name and its contents, so it's impossible for two different components to generate the same class. The collision problem disappears by construction, not by discipline.

Two useful syntax details:

• styles[bike.type]: bracket access. Since bike.type is 'urbana', 'electrica', or 'carga', we get the matching variant class. This is how data connects to style without a single if.
• Classes with hyphens: if you name a class .featured-card, in JS you'll have to write styles['featured-card']. That's why CSS Modules favor camelCase: .featuredCard → styles.featuredCard.

This is CicloUrbano's default strategy from here on, for three reasons: it adds no dependency, it solves the real problem (collisions) without demanding discipline from anyone, and it's still CSS, so everything you know about the cascade still applies.

When two components need the same rules, there are two clean routes:

composes is a feature of its own in CSS Modules: the resulting class includes both. The simpler alternative is to put those shared rules in the global CSS and combine them with the helper from section 6: className={cx('box', styles.card)}.

The two remaining alternatives are very popular and worth knowing even though we won't use them in the course.

Libraries like styled-components or Emotion let you write CSS inside JavaScript and get back an already-styled component:

Its big appeal is that props determine the style directly, with the full power of CSS. Its drawbacks: one more dependency, a run-time cost (styles are generated while the app is running), friction with server rendering, and a clear ecosystem trend away from this approach toward solutions that resolve at build time (zero-runtime), like Vanilla Extract or Panda CSS.

The opposite approach: instead of writing CSS, you compose predefined atomic classes directly in the JSX.

Advantages: you never switch files to style something, the final CSS is tiny because only the utilities actually used get included, and the design system (spacing, colors, typography) is imposed for you, which gives a lot of consistency. Drawbacks: the JSX fills up with classes and loses readability, there's a learning curve for the names, and composing long conditionals needs a helper library.

Whatever the strategy, there's a constant need: choosing classes based on the data. In CicloUrbano, the status badge must be green if the bike is available, orange if it's rented, and red if it's in maintenance.

The most direct way, and the one you already used in StatusBadge:

status--${status} produces status--disponible, status--alquilada, or status--mantenimiento. One single line covers all three cases, and adding a fourth status needs no change to the component, only to the CSS.

Watch out for one important limit: this works with global CSS, but not with CSS Modules, because a module's classes are renamed. There you have to go through the object:

When the class depends on a boolean:

This turns unreadable fast. With three or four conditions you get monstrous templates, double spaces, and undefined sneaking into the attribute.

The solution is a function that joins the valid names and drops the rest. It's three lines long and you'll use it in every project you write:

How it works, step by step:

• ...names is a rest parameter: it collects every argument into an array.
• .filter(Boolean) drops the falsy values from the array: false, undefined, null, '', and 0. It's an idiomatic shortcut equivalent to .filter(value => Boolean(value)).
• .join(' ') joins what's left with spaces, which is exactly the format className expects.

With it, the JSX becomes readable again:

If featured is false, the expression featured && styles.featured is false, and filter(Boolean) drops it. No ternaries, no empty strings, no stray spaces.

In real projects you'll see the clsx library (or classnames), which does the same thing with more features. Our three-line helper covers the common case without adding dependencies.

And the classes missing from the module:

CicloUrbano's colors have been repeating literally since lesson 01-03: #12805c in five places, #d9e2ec in just as many. Changing the brand green today would mean a find-and-replace across the whole project, risking missing one.

CSS variables (custom properties) solve this natively, with no tools or preprocessors:

And now any style file in the project can use them, including .module.css files, because variables do cross the local scope: what CSS Modules renames are classes, not custom properties.

Concrete advantages:

That last point deserves an example, because it combines the best of strategies 2 and 3:

JavaScript only supplies the data; all the presentation — including the transition, impossible in an inline style — stays in the CSS. It's the recommended pattern for dynamic styles.

It isn't "pick one and drop the rest": the strategies complement each other, and this split is what you'll see in most Vite projects:

Resulting file tree:

With this, BikeCard is finally a complete unit: its markup, its logic, and its style are in the same folder, under the same name, and can be deleted together without leaving a trace. That was the promise from the module's first lesson.

• Using class instead of className. The most repeated React mistake. class is a reserved JavaScript word.
• Forgetting the .module in the file name. BikeCard.css is global; only BikeCard.module.css turns on the local scope. The symptom is that import styles comes back empty and the classes never apply.
• Writing className={styles} instead of className={styles.card}. styles is an object; React ends up painting [object Object] as the class.
• Referring to a class that doesn't exist in the module. styles.crad is undefined and the element ends up with no class, no error at all. It's the hardest bug to spot: always check the generated HTML in the inspector.
• Writing hyphenated CSS in a module and accessing it with a dot. .featured-card forces styles['featured-card']. Use camelCase in modules.
• Inserting false into a class template. `card ${featured && 'featured'}` produces literally "card false" when the condition is false. Use the cx helper or a ternary with an empty string.
• Putting units where React already adds them, or leaving them out where they're needed. In style, width: 300 means 300px, but width: '80%' needs to be a string. And flex: 1 or zIndex: 10 go without a unit.
• Trying :hover with inline styles. It doesn't exist. If you need it, you need a class.
• Tip: start with the CSS variables. Before writing a project's first component, define the palette in :root. It saves a guaranteed refactor.
• Tip: name a module's classes by role, not by appearance. .title and .price age well; .greenText doesn't.
• Tip: if a component needs more than three or four conditional classes, review its design. It's usually a sign that two separate components are needed.
• Note on accessibility: color must never be the only carrier of information. Our StatusBadge gets this right by also showing the status text next to the color. This is covered in depth in Accessibility in Interactive Components.

Migrate StatusBadge from global CSS to CSS Modules. Create src/components/StatusBadge.module.css with a base class and one class per status (disponible, alquilada, mantenimiento), using the palette's CSS variables. Adapt the component so it combines the base class with the one for the status it receives via props, and add a :hover effect that slightly increases the opacity.

Hint: the status class has to come from the styles object, not be built with a template string.

Build the complete StationAvailability component (src/components/StationAvailability.jsx and its CSS module). It should receive a station from the domain and a number of occupied docks, and show the name, the count, and a progress bar. The bar's width must be passed as a CSS variable from the component, and the color must change with occupancy: green below 60%, orange between 60% and 85%, red above that.

Use the cx helper to choose the color class.

For each situation, say which styling strategy you'd choose and why. Justify it in two or three sentences.

1. The margin reset and box-sizing for the whole application.
2. The background color of a table row that depends on the bike's status (three possible values).
3. The exact position of a tooltip, computed from the mouse coordinates.
4. A reusable brand button with :hover, :focus, and :disabled states.
5. CicloUrbano's corporate color palette.

Solution 1.

The key point: className={`status status--${status}`} stops working with modules, because the classes are renamed. You have to look them up in the object with styles[status]. And if an unexpected status arrived, styles[status] would be undefined and the cx helper would drop it without breaking anything: the badge would render with no background color instead of failing.

Solution 2.

Division of responsibilities: the component computes only the data (percentage and level), the CSS module supplies all the presentation — transition included — and the inline style is limited to handing over a variable. Both percentage and level are derived values: neither is state, as you studied in the previous lesson.

Solution 3.

You now know how to style a React component with judgment, not out of habit. You've seen all four strategies on the same BikeCard: global CSS, convenient but with a shared namespace where collisions are only a matter of time; inline styles, unbeatable for values computed at run time and useless for everything else — no :hover, no media queries, no animations; CSS Modules, which Vite supports out of the box and which solve local scope by construction; and the ecosystem's alternatives, CSS-in-JS and utility frameworks, with their trade-offs clearly identified.

CicloUrbano adopts the combination that strikes the best balance: CSS variables in :root for the palette and shapes, a .module.css next to every component for all of its style, and inline styles only to hand over computed values, preferably as a CSS variable so the presentation keeps living in the CSS. Along the way you've picked up two tools you'll use constantly: building classes from data with styles[bike.type], and composing conditional classes with the cx helper, which drops falsy values without cluttering the JSX.

With this you close out Module 2. You know what a component is as a unit of design and how to draw its boundaries; you know how to read legacy code written with classes and why everything new gets written with functions; you know how to parameterize a component with read-only props and compose content with children; you know how to give it memory with state, update it immutably, and tell what should be stored apart from what should be derived; and now you know how to dress it without the style spiraling out of control. BikeCard is, at last, a complete unit: markup, logic, and style in the same folder.

But the catalogue is still just a showcase. TypeSelector remembers the chosen type and filters nothing; DockCounter subtracts docks that matter to no one else; there are no forms, no validation, and lists are still written card by card. Real interaction is missing. In Module 3: Working with Events you'll learn to handle React events with all their rules, to show or hide parts of the interface with conditional rendering, to paint whole collections with map and finally understand what the keys you saw in reconciliation are for, to build controlled forms and validate them, and to make all of it accessible. The next lesson is Handling Events in React, and from there CicloUrbano will stop just looking at itself and start responding.