You've been using a hook since lesson 02-04 without putting a name to the category: useState. And the last two lessons have surfaced the historical reasons hooks exist: the wrapper hell of HOCs and render props (04-02), and related logic scattered across lifecycle methods that sat fifty lines apart from each other (04-03). This lesson closes that loop. You'll understand exactly what a hook is, what problem it came to solve, why it has two apparently arbitrary rules of use — and the internal mechanism that explains them —, what hooks exist and which lesson in the course covers each one. We won't develop any of them in depth here: that's the job of the entire Module 5. Here we're laying out the map before we walk the territory.

1. What problem hooks came to solve
2. What a hook is, precisely
3. Rule 1: only at the top level
4. The mechanism: the ordered list of hooks
5. Rule 2: only from components or from other hooks
6. eslint-plugin-react-hooks, the safety net
7. Catalogue of the course's hooks
8. Combined basic use: SummaryPanel with useState + useEffect
9. Local state, ref, and context: three different things

Before 2019, a React component had to pick between two incompatible shapes:

• Function component: simple, readable, no this… but no state and no access to the lifecycle. Good only for presentation.
• Class component: could do everything, at the cost of a constructor, bind, this, and lifecycle methods.

That forced a full refactor the moment a presentational component needed to remember a piece of data. But the deeper problem was something else, and worse: there was no decent way to reuse stateful logic.

Say three CicloUrbano components need to know the window's width to decide how many cards fit. With classes, the logic — subscribe to the resize event, store the width, unsubscribe — had to be copied into all three, or the three had to be wrapped in a HOC, or nested inside a render prop. The last two options produced trees like this one:

Four levels that paint nothing, props that appear with no visible origin, and awkward debugging. That's the wrapper hell you saw in 04-02.

The second problem was organization by moment instead of by subject, which we analysed in 04-03:

Three concerns that have nothing to do with each other share a method, and each one has its other half in a different method. It's the perfect recipe for forgetting a cleanup.

Hooks solve all three at once:

And one thing they didn't do: get rid of classes. They still work, and error boundaries still require them (04-05).

A hook is a JavaScript function whose name starts with use and that hooks the component into React's internal system, giving it access to capabilities like state, effects, or context.

Let's unpack the definition:

• It's an ordinary function. It isn't a language keyword, it isn't special syntax, it doesn't require compilation. useState is a function React exports and you import.
• Its name starts with use. That's not decorative: it's the convention by which React and analysis tools recognize a hook. eslint-plugin-react-hooks decides whether a function is a hook by looking at its name, and applies the rules accordingly. If you write your own stateful function and call it getWidth instead of useWidth, the rules won't apply and you'll lose the safety net.
• It hooks into the internal system. Here's the conceptual key. A function component is just a function: when it finishes, its variables disappear. So where does state get stored between renders? Outside the component, in an internal data structure of React's, tied to that specific instance. The hook is the cable that connects the function to that store.

That idea — state lives in React, not in the function — is what makes the two rules in the next section possible. It also explains something you already noticed in 02-04: two instances of the same component have independent states, because React keeps one store per instance, not per component.

Call hooks only at the top level of the component. Never inside conditionals, loops, nested functions, or after an early return.

The last case has a conceptual fix, not a technical one: if each station needs its own state, each station needs its own component. You extract DockCounter and call the hook inside it. Each instance gets its own store, and the rule holds on its own.

Why such strict rules? Because React's internal mechanism depends on order. Let's see it.

React doesn't store state by the variable's name. It can't: const [hours, setHours] is array destructuring, and React never sees the name hours. What it does is much simpler: for every component instance, it keeps an ordered list of cells, and a pointer that moves forward one position with every hook call.

On the first render React creates the cells in the order the hooks are called. On every subsequent render it simply reads them in the same order. The link between useState(1) and its stored value is exclusively position.

That's where the rule comes from: if a render calls three hooks and the next one calls only two, the positions shift and every variable ends up with someone else's value.

The result on screen: confirmed ends up holding '' instead of false, and setConfirmed writes into the cell that used to belong to note. There's no syntax error, the app doesn't crash, and the bug shows up as absurd behaviour that's very hard to trace. React catches many of these cases and warns with:

When you see that message, look for a hook inside an if, a loop, a try/catch, or after an early return. It's always that.

The practical consequence: the number and order of hook calls must be identical on every render of a component. That's why hooks are all written together, right at the top, before any conditional logic. And if you need a conditional value, the condition goes inside the hook, not around it:

Call hooks only from React function components or from other custom hooks. Never from plain JavaScript functions.

The reason follows straight from the previous section: the cells belong to a component instance that's rendering right now. If you call a hook from a loose function, React has no idea which cell list to reach for, and it throws:

The event handler case deserves a warning, because it's a frequent mistake for beginners: handlers run after render, once no rendering is in progress anymore. Hooks get called during render; handlers use whatever those hooks returned.

And the constructive consequence of this rule is the one that gives everything meaning: a function whose name starts with use and calls hooks is a custom hook, and that's all it takes to reuse stateful logic. No wrappers, no new levels in the tree. You'll build one in Custom Hooks.

The two rules are easy to break without noticing, especially while refactoring. That's why the React team maintains an ESLint plugin that checks them automatically, and that Vite's React templates already ship configured.

What each rule contributes:

The first rule is wrong so rarely that it's worth treating as a compile error. If you're ever tempted to silence it with a comment, the correct answer is almost always to restructure the component — extract a child component, move the condition inside the hook — not to silence the warning.

Here's the full map. Don't memorize the details now: the right-hand column tells you where each one gets explained in depth.

Two observations about the catalogue:

• Most components only need useState. After that, by frequency, come useEffect and useContext. useMemo and useCallback are optimization tools that only apply once you've measured a problem, and that's exactly why they show up in module 8.
• There are more hooks than the ones listed here (useImperativeHandle, useSyncExternalStore, useDebugValue, useOptimistic, useActionState…). They're specialized, and this course leaves them out except for the odd mention. The table above covers ninety-five percent of the React written on a daily basis.

A taste of module 5. This CicloUrbano component combines the two hooks you'll use most: it keeps a count of how many times the summary has been queried, and it synchronizes the browser tab's title with the available fleet.

What each piece does and why it's where it is:

• The two useState calls sit at the top, at the top level, one after the other. They occupy cells 0 and 1, in that order, on every render. Rule 1 satisfied.
• available and inMaintenance aren't state. They're computed from fleet on every render. If they were state, you'd have to recompute them by hand every time the fleet changed, with the desync risk you saw in 04-01.
• setQueries((previousQueries) => …) uses the functional form because the new value depends on the previous one. It's the precaution from 02-04.
• The useEffect synchronizes with an external system: document.title belongs to the browser, not to React. This is where the mental model from 04-03 applies: it's not about "running code on mount," it's about keeping the title synchronized with available. That's why available shows up in the dependency list [available]: whenever that number changes, the synchronization gets redone.
• handleQuery doesn't call any hook. It uses the hooks' results (setQueries, setMessage, available), which is exactly the correct division of labour under rule 2.
• The aria-live="polite" comes from 03-06: the message changes without the person's focus moving, and it needs to be announced.

And in App, with no ceremony at all:

No HOC, no render props, no extra level in the tree. Two function calls inside the component, and it already has state and effects. That's the contribution of hooks, summed up in one example.

To close out the map, the distinction that will organize most of the decisions you'll make in module 5:

In one sentence each:

• State: "what's on screen, and when it changes it needs repainting."
• Ref: "what gets remembered between renders without anyone having to repaint." It's exactly the this.timer from ActivityPanel's class in 04-03.
• Context: "what's available to a whole subtree without passing it hand to hand," the answer to the prop drilling left open in 04-01.

• A hook inside an if, a loop, or a try. It breaks the correspondence by position and causes incomprehensible bugs. If you need conditionality, move the condition inside the hook or extract a child component.
• A hook after an early return. It's the same mistake in disguise: the return makes the following lines not run on some renders. All hooks go before any return.
• Calling a hook from an event handler. Handlers run outside of render. Call the hook above and use its result inside the handler.
• Naming a function that calls hooks getSomething. Without the use prefix, the ESLint plugin doesn't recognize it as a hook and checks nothing inside it. The convention is functional, not cosmetic.
• Believing that useState in a loop gives "one state per item." It doesn't: it gives a disaster. One state per item means one component per item.
• Silencing rules-of-hooks with an ESLint comment. That's treating the symptom. The rule is practically never wrong.
• Tip: write all the hooks together, at the start of the component. State, refs, context, and effects, in that order, then the derived logic, the handlers, and the return. Keep that layout across the whole project and following the rules becomes automatic.
• Tip: look at hooks in React DevTools. Selecting a function component shows you the list of its hooks in order, with their values. It's the cell list from section 4, made visible.

Exercise 1. This CicloUrbano component breaks the rules of hooks in three different places. Identify each violation, explain which rule it breaks and what concrete consequence it has, and rewrite the component correctly.

Exercise 2. Without writing code, say which hook you'd use for each CicloUrbano situation and which lesson covers it. Justify each choice briefly.

1. Remember which bike type is filtered in the catalogue.
2. Store a setTimeout's identifier so it can be cancelled.
3. Have fifteen components scattered across the tree know the signed-in user.
4. Keep document.title up to date with the number of active bookings.
5. Manage a booking form with eight fields and complex transitions between validation states.

Exercise 3. Extend section 8's SummaryPanel with a third piece of state, lastQuery, that stores the time of the last query as a readable string (toLocaleTimeString('en-GB')), or null if it hasn't been queried yet. Show it on screen only when it exists. Then answer: which position in the cell list does this new state land on, and why does it matter where you declare it?

Solution 1. The three violations:

1. Early return before a hook (rule 1). When station is null, the function ends before reaching the following calls, and the number of hooks executed changes between renders. What's more, useState(station.docks) on the line above would already have blown up trying to read .docks off null: the guard arrives too late.
2. useState inside an if (rule 1). detailOpen only gets created when showDetail is true; when that prop changes, the cells shift and the states get mixed up with each other.
3. useState inside an event handler (rule 2). handleRental runs after render, when there's no render in progress: React throws "Invalid hook call."

And a fourth problem, not about the rules but about correctness: setFreeDocks(freeDocks + 1) should use the functional form, and it also has no upper bound (it could exceed the station's total docks).

Notice the general pattern behind the fix: hooks are always all declared; what's conditional is the use of their value in the JSX, not the call itself.

Solution 2.

Solution 3.

lastQuery occupies cell 2, because it's the third hook called. What matters isn't the number itself, but that that position stays the same across every render: that's why the declaration sits at the top level, next to the other two, and not inside the if that decides whether to show it. The condition applies only to the JSX ({lastQuery && …}), never to the hook call. If you had declared it inside a conditional, on the renders where that condition didn't hold, useEffect would end up reading the wrong cell.

A hook is a function whose name starts with use and that hooks a function component into React's internal system, giving it access to state, effects, context, and everything that used to require a class. Hooks were born to solve three concrete problems classes carried with them: the impossibility of giving state to a function, the wrapper hell produced by HOCs and render props (04-02), and the logic of a single concern scattered across lifecycle methods (04-03).

Their two rules — only at the top level and only from components or from other hooks — aren't stylistic whims: they're explained by the mechanism of the ordered cell list React keeps per instance. The link between a useState call and its stored value is position, and that's why the number and order of the calls must be identical on every render. eslint-plugin-react-hooks watches both rules for you, and it's worth treating rules-of-hooks as an error. You also now have the full map: which hooks exist, what each one is for, and which lesson covers it; plus a first SummaryPanel from CicloUrbano that combines useState with useEffect without a single wrapper.

One piece remains to close out the module, and it's the exception that proves everything above. Hooks have replaced lifecycle methods in everything… except one case: catching errors a component throws during render. If a CicloUrbano card blows up on unexpected data, React unmounts the whole tree and the person is left staring at a blank page. Avoiding that requires a tool that, to this day, still requires a class component. The next lesson is Error Boundaries: Catching Failures in the UI.