04-03 left a promise on the table: the correct mental model for what classes used to call the "lifecycle" isn't a sequence of moments (componentDidMount, componentDidUpdate, componentWillUnmount), but rather synchronizing with an external system. This lesson delivers on that promise. useEffect is the tool that connects a React component with everything that lives outside React: timers, browser events, the tab title, a network connection, a server. But before learning how to use it, you have to learn how not to use it, because useEffect is the most misused hook in the ecosystem: people stuff it with logic that belongs in the render or in an event handler, and the result is extra renders, flicker, infinite loops, and bugs that are impossible to reproduce. Here you'll see its full anatomy, when it actually runs, why StrictMode calls it twice and why that's a good thing, four legitimate cases in CicloUrbano — including data loading with race conditions — and the antipatterns you need to recognize on sight.

1. What is an effect, and what isn't
2. Most code doesn't need useEffect
3. Anatomy: effect function, cleanup, and dependencies
4. The three forms of the dependency array
5. The real execution cycle
6. StrictMode, the double execution, and the cleanup test
7. Case 1: an availability timer
8. Case 2: listening to a browser event
9. Case 3: loading data from an API and the race condition
10. Case 4: synchronizing the document title
11. The dependency array in depth
12. Infinite loops: real causes and real fixes
13. Antipatterns you need to recognize
14. useLayoutEffect and modern data loading

Let's start with a precise definition, because the word "effect" gets misused constantly.

An effect is a piece of code that synchronizes the component with a system external to React, and that React runs after painting the screen, not during render.

Both parts matter. "External system" means anything React doesn't control:

And now what an effect is not, which is where most of the mistakes are:

The question that separates one case from the other is simple: does this happen because the user did something specific, or because the component is on screen? If it's the former, it goes in a handler. If it's the latter, it's an effect.

This deserves its own section because it's the single most valuable piece of advice in the whole lesson. Here are the three cases where people reach for useEffect without needing it.

This code works, but it triggers two renders per change: one with the old list, and another, after the effect, with the new one. For a fraction of a second the screen shows incorrect data. And if you forget a dependency, it shows incorrect data forever.

One render, always consistent, impossible to desynchronize. If the computation were genuinely expensive, the fix isn't an effect — it's useMemo (08-03).

The effect-based version has a serious flaw: if the bookingConfirmed state gets set back to true for some other reason — reloading a saved draft, for instance — the analytics fire again. The handler only runs when someone actually presses the button, which is exactly what we want to measure.

The rule that sums up this section: if you can compute it during render or do it in a handler, it isn't an effect.

The three pieces, one by one:

• The effect function contains whatever needs to happen to start synchronizing. React runs it after applying changes to the DOM and after the browser has painted, so it never blocks the interface.
• The cleanup function is what the effect function returns. It contains whatever's needed to stop synchronizing. React runs it right before re-running the effect, and also when the component unmounts. If your effect creates, opens, subscribes to, or starts something, the cleanup must destroy it, close it, unsubscribe from it, or stop it. It's an almost mechanical symmetry:

• The dependency array tells React which values the synchronization depends on. If none of them changed compared to the previous render, React skips the effect entirely.

Examples of all three, with the same component:

Dependencies are compared with Object.is, meaning by reference for objects, arrays, and functions. This is the cause of 90% of infinite loops, and we cover it in section 12.

This diagram permanently replaces the lifecycle-methods table:

What to hold on to: cleanup and effect are always paired. A new effect never runs without the previous one having been cleaned up first. That's why the "mount / update / unmount" mental model is misleading: from useEffect's point of view there aren't three distinct moments, only start synchronizing and stop synchronizing, repeated as many times as needed.

Translated to CicloUrbano: if the panel is connected to station est-01 and the user switches to est-02, React closes the connection to est-01 and opens one to est-02. That "change" isn't a special case — it's a stop followed by a start.

In 01-03 you saw that <StrictMode> mounts every component twice in development. With effects the behavior is even more striking: React runs the effect, runs its cleanup, and runs the effect again, all during the initial mount.

A lot of people react by removing StrictMode. That's exactly the wrong move. What React is actually doing is putting your effect through a test: if the component unmounts and remounts (which happens constantly in real applications when navigating between routes, as you'll see in 06-01), does everything end up back where it should be?

• If your effect is written correctly, the "effect → cleanup → effect" sequence leaves the system in the same state as a single run. You notice nothing.
• If it's missing the cleanup, the double execution makes it visible: two timers running at once, two subscriptions, two requests. The bug was already there; StrictMode just surfaces it in development instead of in production.

In production, StrictMode doesn't duplicate anything. The golden rule: if removing StrictMode fixes your problem, the problem is still there.

The first legitimate case. StationAvailability checks every ten seconds how many free docks a station has and displays it on screen.

Details that make this effect correct:

• The dependency is station.id, not station. The station object might be a fresh reference on every render of the parent even when the data is identical, which would restart the timer constantly. The id is a string: it's compared by value.
• intervalMs is in the dependencies because the timer depends on it. If the parent changes the frequency, the synchronization has to be redone.
• setFreeDocks is not in the dependencies: updaters are stable (05-01, section 2).
• The cleanup cancels the timer. Without it, switching stations would leave the previous timer running forever, writing into a component that's already showing a different station.

CicloUrbano needs to warn the user when the device loses its connection, because bookings can't be confirmed without a network.

Three observations:

• The handler functions are declared inside the effect. If they lived outside, in the component body, they'd be fresh references on every render and the linter would demand you include them in the dependencies, which would restart the subscription for no reason.
• removeEventListener needs the exact same reference that was passed to addEventListener. Writing window.removeEventListener('online', () => setIsOnline(true)) removes nothing, because it's a different function. This mistake leaves listeners piling up and is a classic memory leak.
• The initial state uses lazy initialization (() => navigator.onLine) so it doesn't query the browser API on every render.

The most common case, and the one that causes the most trouble. Let's start with the naive version:

The problem has a name: race condition. If the user selects est-01 and then quickly est-02, two requests get sent. Nothing guarantees they'll arrive in order.

There are two solutions, and the idiomatic move is to apply both.

Use the cleanup to mark the previous response as stale:

The key is that every run of the effect has its own ignore variable, thanks to JavaScript's closures. When stationId changes, React runs the cleanup for the old effect, which sets its ignore to true. If that response arrives late, it gets discarded.

The flag prevents the bug, but the request keeps traveling and consuming bandwidth. AbortController actually cancels it:

Two technical details that often get overlooked:

• The effect function can't be async. An async function returns a promise, and React expects the returned value to be the cleanup function. That's why load() is declared inside and called; never useEffect(async () => {…}, []).
• fetch doesn't throw on a 404 or a 500. It only throws when the network itself fails. You have to check response.ok by hand, as the example does.
• The state structure follows principle 3 from 05-01: loadState is a string with mutually exclusive values, not three booleans that could contradict each other.

The smallest case, and the most instructive one, because it teaches the key word: synchronize.

We're not "running code on mount": we're declaring that the tab title must always reflect the number of available bikes. React takes care of redoing it whenever that number changes. That shift in perspective — from "when does this run" to "what needs to stay true" — is the mental model promised back in 04-03.

If you wanted to be strict about it, the cleanup would restore the original title on unmount:

Every reactive value used inside the effect. A value is reactive if it's declared inside the component and can change between renders: props, state, and any variable or function derived from them.

It's tempting to drop a dependency to make the effect "stop firing." It never works: the effect will keep using the value from the render it last ran in — that is, a frozen value (the snapshot from 05-01).

The user switches stations, the interface shows est-02, and the data that arrives is still est-01's. It's exactly the kind of bug nobody reproduces and that shows up in production.

eslint-plugin-react-hooks (04-04) includes the exhaustive-deps rule, which compares what's inside the effect against the array and warns about what's missing:

Treat it as an error, not a suggestion. And never silence it with // eslint-disable-next-line react-hooks/exhaustive-deps: if the warning bothers you, the fix isn't muting it — it's changing the code so the dependency stops being a problem.

Symptom: the tab freezes, the console spits out thousands of lines, or React throws "Maximum update depth exceeded." It's always the same structure: the effect changes something that's in its own dependencies.

Every render creates a different object; React sees a changed dependency, runs the effect, the effect updates state, that triggers a render, which creates another object… Solutions, in order of preference:

Moving the function inside the effect is almost always the right fix, and it has an added benefit: the linter can genuinely analyze what the function uses and compute the real dependencies. useCallback also solves this, but it's a memoization tool covered in 08-03, and using it here would be swinging a sledgehammer at a thumbtack.

If the goal is to count something, that's almost never an effect's job. If it genuinely were, the functional form lets you drop the dependency:

This chain is fragile (changing the order breaks it), slow (one render per link), and impossible to follow when reading it. The correct version does all the work in the handler that started the action and derives the rest:

There's a variant, useLayoutEffect, that runs after the commit but before the browser paints; it's reserved for measuring the DOM and adjusting something's position so no flicker is visible (a tooltip that needs to fit on screen), and misusing it blocks painting, so the default choice is always useEffect.

And a caveat about section 9: even though loading data with useEffect is perfectly valid and worth understanding thoroughly — it's what sits underneath everything else — in a production application you don't write it by hand. You'd be missing the cache shared across screens, deduplication of simultaneous requests, retries, revalidation when returning to the tab, and invalidation after a write. All of that gets solved by server-state libraries like TanStack Query or SWR, and also by the data loaders built into routers (Module 6) and frameworks like Next.js (Module 10). That's the subject of 07-06; for now, hold on to the underlying mechanism — it's what will let you understand those tools instead of using them blindly.

• Using useEffect to transform data. The tell is a useState that only ever gets updated inside an effect. It's almost always a derived value in disguise.
• Forgetting the cleanup. Timers and listeners that outlive the component are memory leaks and phantom updates. If the effect starts something, the cleanup stops it.
• Passing a different function to removeEventListener. Store the function in a constant inside the effect and use that same reference in both calls.
• Declaring the effect function as async. React would interpret the returned promise as the cleanup function. Declare an inner function and call it instead.
• Silencing exhaustive-deps. The warning points at a real problem; hiding it just turns it into a production bug.
• Depending on an object or array created during render. It's the most common cause of infinite loops. Depend on primitives instead.
• Removing StrictMode because "the effect runs twice". The problem is the missing cleanup, not StrictMode.
• Not checking response.ok. fetch treats a 500 as a perfectly valid response.
• Tip: before writing an effect, say out loud "this component needs to stay synchronized with ___." If you can't finish that sentence with an external system, it isn't an effect.
• Tip: a console.log at the start of the effect and another in the cleanup, printing the dependency's value, resolves most questions about when things run.

Exercise 1. This StationClock from CicloUrbano — the one that showed up in exercise 2 of 04-03 — has three bugs related to useEffect. Find them, explain what each one causes, and write the corrected version.

Exercise 2. Write BikeSearch with a delay (debounce): the component keeps its own local query state (04-01) and must notify the parent with onSearch(query) only once the user has gone 400 ms without typing. Use useEffect with cleanup. Explain why the cleanup is exactly what produces the delay.

Exercise 3. The following component loads a station's detail record and has both a race condition and a leak. Rewrite it using the state structure from section 9 (a single phase variable), AbortController, an ignore flag, and HTTP error handling.

Solution 1.

The three bugs:

1. The first effect has no dependency array: it runs after every render. Since the effect itself updates time, every tick triggers a render that creates another timer. After a minute there are dozens running at once and the clock jumps forward in leaps.
2. The first effect has no cleanup: even with [], StrictMode would leave two timers running, and on unmount the timer would keep calling setTime on a component that no longer exists.
3. The second effect is derived state in disguise: formattedTime is computed entirely from time and timeZone. Both the state and the effect are unnecessary; on top of that it causes an extra render every second and makes the first render show an empty string.

Solution 2.

Why the cleanup produces the delay: every keystroke changes query, so React first runs the previous effect's cleanup — which cancels the pending timer — and then the new effect, which schedules another one 400 ms out. As long as the user keeps typing, no timer ever gets to fire: each one dies canceled by the next keystroke. Only once 400 ms pass with no changes does the last one survive and call onSearch. The delay isn't programmed anywhere explicitly: it emerges from the effect/cleanup pair.

Note: onSearch is in the dependencies because the linter requires it and it's a reactive value. If the parent recreates it on every render, this would restart the timer constantly; it gets solved with useCallback in the parent (08-03) or, better, by extracting the logic into a useDebounce hook, which is exactly what you'll do in 05-06.

Solution 3.

The problems with the original, and their fixes: it didn't cancel the previous request when stationId changed (race condition); it left loading stuck at true forever if the request failed, because the .catch never turned it off (contradictory state, principle 3 from 05-01); it treated a 404 as success, because fetch doesn't throw on error HTTP responses; and it could try to read station.name while station was still null. The single phase variable eliminates the impossible combinations at the root.

useEffect isn't "code that runs on mount": it's the tool for synchronizing a component with an external system, with two symmetric operations — start and stop synchronizing — that React repeats as many times as needed. You've seen its anatomy (effect, cleanup, dependencies), the three forms of the array and when each one fires, the real cycle with cleanup always paired to the effect, and why StrictMode's double execution is a free test that your cleanup is done right. With CicloUrbano you've written the four legitimate cases: an availability timer, a subscription to browser events, data loading with AbortController and an ignore flag against the race condition, and synchronizing the document title. And, above all, you've learned when not to use it: transforming data is render, responding to a click is a handler, resetting state is key, and chained effects are a cascade of renders that almost always hides a derived value gone wrong.

One piece is left that's shown up in passing several times. Section 7's timer returned an id that had to be kept around; exercise 2's search box needed to remember the pending timer; and 03-05 mentioned a way to read a form field by reaching straight into the DOM node. All of that comes down to values that need to be remembered across renders but must never trigger one, plus React's controlled escape hatch to the page's real elements: focusing a field, measuring an element, scrolling a list, opening a <dialog>. The next lesson is The useRef Hook and DOM Access.