At the close of the previous module we left off with a confession: CicloUrbano's catalogue is a shop window. Data arrives, cards paint themselves with their colour and status badge, but the app doesn't react to anything the person using it does. What's missing is the wire that connects the interface to the logic, and that wire is events. In this lesson you'll learn how React connects a click, a keystroke or a focus change to a function of yours: the exact syntax, the classic mistake of calling the handler instead of passing it, what a synthetic event is and what API it offers, how to pass arguments, how bubbling and capturing work, and how to name handlers so the code is still readable six months from now. By the end, TypeSelector will stop being a mock-up and BikeCard will let its parent know which bike was clicked.

1. What an event handler is and where it lives
2. onClick versus onclick: the real differences
3. Pass the function, don't call it
4. The synthetic event object
5. preventDefault and stopPropagation
6. Handlers with arguments: inline arrow functions
7. Bubbling and capturing
8. Catalogue of common events
9. Where to define the handler and how to name it
10. CicloUrbano: a selector that responds and a card that notifies

An event handler is an ordinary function that React runs when something happens in the interface: a click, a keystroke, a form submission. There's nothing special about it: it's a plain JavaScript function declared inside your component's body.

Three details worth fixing in your mind from minute one:

• The function is declared inside the component, not outside. That way it can read that specific instance's props and state, which is exactly what it'll need as soon as it does something useful.
• onClick is a prop, not an HTML attribute. It's written in camelCase, like className or tabIndex, because JSX uses property names, not attribute names.
• The value goes inside curly braces, because it's a JavaScript expression: the reference to the function. In quotes it would be a plain string, and React would warn you with an error.

This pattern — declare the function above, reference it below — is what you'll see in 95% of the React code you come across.

If you come from framework-free JavaScript you know two ways of listening for a click: the onclick="..." HTML attribute and element.addEventListener('click', fn) in the script. React replaces both with a third.

Look at the two most important rows. The first is that in React the value is a function, not a string of code: there's no evaluating text, the editor autocompletes, and syntax errors are caught at compile time. The second is that you don't have to remove the listener: when the component disappears from the screen, React cleans up for you. With manual addEventListener, forgetting the matching removeEventListener is one of the most common sources of memory leaks.

One technical nuance worth knowing, even though it doesn't change how you write code: React does not attach a listener to every <button>. It attaches a handful of listeners to the app's root node (the <div id="root"> you saw in lesson 01-03) and, when an event arrives, decides which of your handlers should run. This technique is called event delegation, and it's what lets a thousand buttons on screen cost far fewer than a thousand listeners.

This is the most common mistake among people starting out with events in React, and it earns its own section because the symptom is so misleading.

What exactly happens in the second line? Remember that JSX is evaluated while rendering. The parentheses run the function right then, and what gets assigned to onClick isn't the function, but its return value. Since handleClick doesn't return anything, onClick ends up being undefined.

The consequences, in order of appearance:

1. The console.log message shows up the moment the page loads, without anyone having clicked anything.
2. Clicking the button does absolutely nothing, because onClick is undefined.
3. If the handler updates state, it triggers a new render, which calls the function again, which updates state again… an infinite loop, and the tab freezes with a "Too many re-renders" error.

The mnemonic rule is simple: with parentheses, now; without parentheses, later.

The third form is valid, and you'll need it in section 6, once you have to pass arguments. But if the handler takes no arguments, write the first form: it's shorter and more direct.

When React runs your handler, it passes it one argument: the event object.

It isn't the browser's native event: it's a synthetic event (SyntheticEvent), an object React builds by wrapping the native one.

In the years React was born, every browser exposed events in slightly different ways: different property names, incompatible behaviour, a preventDefault that some browsers called something else entirely. The synthetic event solves three things:

The synthetic API mirrors the native one, so everything you already know about DOM events still holds. The properties and methods you'll use daily:

The distinction between target and currentTarget matters. If a <button> contains a <span> and you click on the text, event.target will be the <span>, while event.currentTarget will be the <button>. Whenever you want to identify "the element I attached the handler to", always use currentTarget.

A useful bit of history: up to React 16, synthetic events were pooled and reused: as soon as the handler finished, its properties were wiped, and reading them later required calling event.persist(). That disappeared as of React 17. If you find event.persist() in a tutorial, it's old code: in React 19 it isn't needed and does nothing.

These are two distinct methods that get confused constantly. They do things that have nothing to do with each other.

Some elements have a native behaviour attached: an <a href> navigates, a <form> submits and reloads the page, an <input type="checkbox"> toggles. preventDefault() cancels that behaviour.

There's an important nuance in React: returning false from the handler cancels nothing. In classic HTML, onclick="return false" did the trick. In React the return value is ignored entirely: you have to call event.preventDefault() explicitly.

Its most frequent use, by far, is submitting forms, which you'll see in depth in Forms and Controlled Components.

Stops the event from bubbling further up towards ancestor elements. It's the tool for the "I have a button inside a clickable card and I don't want clicking the button to also select the card" case.

The two are independent: you can call one, the other, both, or neither.

Very often the handler needs to know what was acted on: which bike type, which id, which row. And there it collides with section 3's rule: you can't write onClick={selectType('urbana')}, because that would run it during render.

The idiomatic solution is to wrap it in an inline arrow function:

Step by step, here's what happens:

1. () => selectType('urbana') creates a new function that doesn't run yet.
2. That function is what gets assigned to onClick.
3. When someone clicks, React calls that function, and only then does selectType('urbana') run.

If you also need the event object, declare it as the arrow's parameter and pass it along:

There's an equivalent, slightly more sophisticated pattern, called currying:

Here onSelectType('urbana') does run during render, but that's fine: what it returns is another function, and that's what gets assigned to onClick. It's correct, though for beginners the inline arrow is easier to read.

Every time the component renders, the expression () => selectType('urbana') produces a new function. It's a different object from the one before, even though it does exactly the same thing.

Is that a problem? In the vast majority of cases, no. Creating a function in JavaScript is an extremely cheap operation, and the readability you gain more than makes up for it. It only starts to matter when that function is passed as a prop to a memoized component, because then the new reference breaks the memoization and causes unnecessary renders.

That scenario, how to measure it and how to fix it with useCallback, is material for Module 8, specifically The useMemo and useCallback Hooks. For now, keep the practical rule: write inline arrows without fear, and only optimize once you measure a real problem.

When you click a nested element, the event doesn't only affect that element: it travels through the tree in two phases.

1. Capture phase: the event descends from the root down to the clicked element.
2. Bubble phase (bubbling): the event ascends from the clicked element back up to the root.

React lets you listen in both phases. By default, onClick listens during bubbling. Adding the Capture suffix — onClickCapture, onFocusCapture, onKeyDownCapture — makes you listen during capture.

Let's see it with an example that prints the full path:

Clicking the button, the console prints all six messages in exactly that order: 1, 2, 3, 4, 5, 6.

One important detail: stopPropagation() cuts the path from wherever it's called. If you call it in article's capture phase, the button won't even get to receive its own click. Use it carefully: cutting propagation can break functionality in other components that relied on receiving that event.

React supports practically every DOM event, always in camelCase. These are the ones you'll use constantly:

Two warnings about this table:

• React's onChange isn't the DOM's change. The native one only fires when the field loses focus after having changed; React's fires on every keystroke. This difference is what makes 03-04's controlled components possible.
• onMouseEnter and onMouseLeave don't bubble, unlike onMouseOver and onMouseOut. That's why they're recommended for visual effects: they don't fire when passing over the children.

With three handlers the code is still readable; with fifteen, naming discipline is the difference between a maintainable component and a puzzle.

The underlying idea is symmetry: the child declares what can happen to it (onSelect) and the parent decides what to do when it happens (handleSelection).

This pattern is called lifting the handler, and it's the basis of child-to-parent communication in React: props carry data down, function props carry notifications up.

The rule that sums it all up: JSX describes the interface, not the logic. If an onClick contains an if, a try, or three statements, that logic belongs in a named function.

Let's apply all of this to the app. Two concrete changes.

The 02-04 version already used onClick, but with the logic written directly in the JSX. Now that we know how to name and organize handlers, it looks like this:

What changed and why:

• handleTypeSelect is a named function. Before, the logic lived inside onClick; now it does two things (saving the state and notifying the parent), and that no longer fits comfortably in JSX.
• onClick={() => handleTypeSelect(type)}: an inline arrow because we need to pass each button's type. Without it, the function would run during render, as you saw in section 3.
• onTypeChange is an optional function prop. If the parent passes it, the selector notifies it; if not, the component keeps working. This is the groundwork for 04-01, where the state will move up to the parent and the filter will actually work.
• type="button" on the buttons. Without it, a <button> inside a <form> defaults to type="submit" and would submit the form when clicked. It's a cheap precaution that avoids a baffling bug.
• onKeyDown on the container: thanks to bubbling, a single handler covers all four buttons. Pressing Escape while any of them is focused resets the filter to "All".

The two key points:

• onSelect and onBook are optional props. The if (onSelect) check avoids the "onSelect is not a function" error when the parent doesn't pass them. An equally valid alternative is giving a default value: onSelect = () => {}.
• event.stopPropagation() on the button is essential: the button sits inside the <article>, which already listens for clicks, so without cutting the propagation every "Book" click would also trigger the card's selection. This is the canonical use case from section 5.

A note we'll come back to in Accessibility in Interactive Components: putting onClick on an <article> makes it clickable with the mouse, but not with the keyboard. It's a conscious debt we'll settle before closing the module.

BikeList just forwards the two function props to each card. For now App only does console.log: actually storing the selected bike requires the state to live in the parent, and that's exactly the subject of Lifting State Up. What matters here is that the flow already works: the click happens on the card and the information reaches the top.

Open the browser console, click a card and then its "Book" button: you'll see a different message each time, without them mixing up. CicloUrbano now responds.

• Calling the handler instead of passing it. onClick={handleClick()} runs it during render. If it also updates state, you get an infinite loop and the "Too many re-renders" error. No parentheses, or wrap it in an arrow.
• Writing the event name in lowercase. onclick isn't a React prop: React treats it as an unknown attribute and warns in the console, suggesting onClick. Always camelCase.
• Passing the handler as a string. onClick="handleClick()" is HTML syntax; in JSX it assigns a string of text and doesn't work.
• Expecting return false to cancel the default behaviour. In React the return value is ignored: use event.preventDefault().
• Confusing preventDefault with stopPropagation. The first cancels what the browser would do; the second cancels the event's climb. They aren't interchangeable.
• Overusing stopPropagation(). Cutting propagation "just in case" breaks functionality that relies on bubbling, like closing a menu when clicking outside it. Use it only when you have a real conflict.
• Confusing target with currentTarget. If the clickable element contains an icon or a <span>, target will be that child. To identify the handler's own element, use currentTarget.
• Forgetting type="button" on buttons inside a form. The default is submit, so the button will submit the form and the page will reload.
• Using event.persist(). That's React 16-era code. Since React 17 events are no longer pooled and that call is unnecessary.
• Putting onClick on a <div> or an <article>. It works with the mouse and fails with the keyboard. Use a <button> when you can; if you can't, you'll need to add a role, tabIndex and a keyboard handler, as you'll see in 03-06.
• Tip: one handler, one responsibility. If handleClick saves state, notifies the parent, and logs analytics, extract helper functions.
• Tip: make the most of bubbling. A single onKeyDown on the container covers all its children. Less code and fewer chances of missing a case.
• Tip: check with console.log(event) when something doesn't add up. The synthetic object is inspectable and usually reveals right away whether the problem is the wrong element or the wrong event.

Analyse this component and identify three event-related bugs. Explain the symptom of each one and write the fixed version.

Create the BikeRow component (src/components/BikeRow.jsx) as a compact version of the card, meant for a table. It should:

• Receive bike and two function props: onSelect and onMarkMaintenance.
• Render a <tr> row with the model, type, status and price, plus a cell with a "Send to workshop" button.
• Notify with onSelect(bike) when any part of the row is clicked.
• Notify with onMarkMaintenance(bike) when the button is clicked, without also triggering the row's selection.
• Log to the console, using event.currentTarget.tagName, which element each handler ran from, to check the difference from target.

Add fuller keyboard behaviour to TypeSelector, using a single handler on the container:

• Escape resets to type 'todos' (already done).
• The ArrowRight key advances to the next type in the TYPES constant, and ArrowLeft goes back, both circularly (from the last type back to the first and vice versa).
• Any other key should do nothing.

Write only the handler, and explain why it's worth computing the new index from TYPES.indexOf(chosenType).

Solution 1.

The three bugs:

Solution 2.

Clicking the text of a cell, currentTarget is always TR (where the handler lives), while target is TD. Clicking the button, stopPropagation() stops handleRowClick from running: only the button's message appears in the console.

Solution 3.

Computing the index from TYPES.indexOf(chosenType), rather than keeping a separate index state, avoids having two sources of truth that could drift apart: the index is a derived value from the state, exactly as you learned in lesson 02-04. And the modulo operator % gives circular behaviour with no extra if; adding TYPES.length before the modulo is necessary because in JavaScript -1 % 4 is -1, not 3.

Events are the point where the interface stops being a picture and becomes an application. You now know that a handler is an ordinary function declared inside the component and handed to React through a camelCase prop; that the prop receives the function, not its call, and why one extra pair of parentheses can cause anything from a premature message to an infinite render loop; that React hands you a synthetic event that normalizes the API across browsers, with target, currentTarget, preventDefault() and stopPropagation() as everyday tools; that passing arguments means wrapping the handler in an inline arrow, whose cost will only matter once you reach Module 8; and that the event travels through the tree in two phases, with onClick listening during bubbling and onClickCapture during capture.

In CicloUrbano that has become two pieces that now respond: a TypeSelector with named handlers, buttons that highlight the current selection, and keyboard shortcuts; and a BikeCard that accepts the onSelect and onBook function props to notify upward of what happens inside it, with stopPropagation() exactly where it was needed. Data flows down through props; notifications flow up through function props. That two-way flow is React's data flow, and it won't change for the rest of the course.

The app reacts now, but it still always paints the same thing. A bike under maintenance shouldn't offer a "Book" button, a catalogue with no results should say so instead of staying blank, and a notice should only appear when there's something to notify. Painting one thing or another depending on state or props is the next step, and it has more subtlety than it looks — including a trap with the && operator that already peeked through in the JSX lesson. You'll see it in Conditional Rendering.