Lesson 3 · Hooks in depth

Effects (useEffect)

Syncing with the outside world, cleanup, race conditions and when you DON’T need an effect.

Before we start: a cook who only cooks

From the previous lessons you know that a component is a cook who makes a dish (JSX) from a recipe (props and state). It has one strict rule: while cooking, it only cooks. It doesn't call suppliers, turn on the radio or text the guests. Why? Because React can have it cook whenever and as many times as it likes – sometimes it cooks a dish and throws it away again. If the cook called a supplier every time they cooked, the supplier would get dozens of pointless orders.

But a real app has to talk to the outside world: start a timer, connect to a chat, change the tab title, listen to the window size. For that React has effects – tasks that run after the cooking, when the dish is on the table (the page is already rendered).

An effect is like the light in a room

The best way to understand an effect is not as "do something once" but as keeping things in sync. Imagine walking around your flat and wanting the light on in whichever room you're in:

When you enter a room, you switch the light on. (That's the effect.)
When you leave it, you switch it off behind you. (That's the cleanup.)
When you go from the kitchen to the living room, you first switch off in the kitchen and then switch on in the living room. (The dependency changed – the room.)
When you just stand in the kitchen peeling potatoes, you don't touch the light. (The dependency didn't change.)

That's exactly how React runs effects: it switches on when the component appears; switches off and on again when whatever the effect depends on changes; and switches off for the last time when the component disappears. You just describe how to switch on and how to switch off.

1. The first effect: the tab title

We want the browser tab's title to show the number of unread messages: "(3) React Course". But the title doesn't belong to React – it lives in document.title, outside JSX. So it's "the outside world" that we need to keep in sync with.

function Inbox() {
  const [unread, setUnread] = useState(0)

  // ❌ Not like this: writing to the outside world right while cooking
  // document.title = `(${unread}) React Course`

  // ✅ An effect: runs only after rendering
  useEffect(() => {
    document.title = `(${unread}) React Course`
  }, [unread])

  return <button onClick={() => setUnread((u) => u + 1)}>A message arrived</button>
}

What happens after a click:

setUnread orders a new render. React calls Inbox() – the cook makes new JSX. Nobody has touched the title yet.
React reflects the changes on the page (the button, the texts).
Only then does React go through the effects. It looks at the array [unread]: has the value changed since last time? Yes (0 → 1), so it runs the effect and the title is rewritten.

So the function passed to useEffect is "what to do after rendering". The array at the end is the list of values the effect depends on – we'll look at it in detail in section 3.

Demo

The tab title from state

What you see: A counter of unread messages. The effect writes it into the title of this browser tab and restores the title in its cleanup.

Try it:

Click A message arrived three times and look at the tab at the top of the browser. The title starts with "(3)".
Click Mark all as read. The title is back without a number.
Add a few messages and go to another lesson. The title is cleaned up – the component disappeared and React called its cleanup.

The takeaway: The state is in React, the title outside it. The effect keeps them in sync: after every change of unread it updates the title, and when leaving it cleans up after itself.

Loading the interactive part…

2. Cleaning up after yourself: cleanup

Some effects start something that keeps running on its own: a timer, a connection to a server, a window event listener. That's like switching on a light – it won't switch itself off. Whoever doesn't switch off behind them pays a big electricity bill a month later. In an app this is called a memory leak: timers keep running even though their component disappeared long ago.

A typical example: a clock that updates every second.

function Clock() {
  const [now, setNow] = useState(() => new Date())

  useEffect(() => {
    // Switch on: start an interval
    const id = setInterval(() => setNow(new Date()), 1000)

    // Switch off: a function React calls during cleanup
    return () => clearInterval(id)
  }, [])

  return <p>{now.toLocaleTimeString()}</p>
}

The function the effect returns is the cleanup. React keeps it and calls it at the right moment.
The empty array [] means "the effect depends on nothing". It runs once when the clock appears, and the cleanup happens when it disappears.
Without the cleanup, after the clock was unmounted the interval would keep calling setNow on a component that no longer exists. And every new mount would add another interval.

The whole life of such an effect:

What happens	What React does
The clock appears on the page	Runs the effect → the interval runs.
The clock re-renders every second	Nothing – the dependencies [] didn’t change, the effect stays.
The clock disappears from the page	Calls the cleanup → the interval is cancelled.

Demo

An effect and its cleanup – an interval

What you see: The clock from the example above. Below it is a log, into which the effect writes "▶ starting the interval" and the cleanup "■ cancelling the interval".

Try it:

Right after loading you'll see three lines in the log: starting → cancelling → starting. Development mode does that on purpose: it mounts the component, unmounts it and mounts it again to check that the cleanup works. In production the effect runs only once.
Click Unmount the clock. The clock disappears and "cancelling the interval" appears in the log.
Click Mount the clock. "starting the interval" appears and the clock carries on from the current time.
Notice that nothing is written to the log on every tick of the clock. A re-render alone doesn't run the effect, because no dependency changed.

The takeaway: Every "starting" has its own "cancelling". Thanks to that, two intervals never run at once, however many times the clock is mounted and unmounted.

Loading the interactive part…

3. Dependencies: when to run the effect again

Back to the light. Dependencies are the answer to the question "which room am I in?" As long as you're in the same room, you don't switch anything. When the room changes, you switch off in the old one and switch on in the new one.

A typical example: connecting to a chat room the user picks.

function ChatRoom({ roomId }: { roomId: string }) {
  useEffect(() => {
    const connection = connect(roomId)     // switch on in room roomId
    return () => connection.disconnect()   // switch off in it
  }, [roomId])                             // the room I'm in

  return <h3>Welcome to #{roomId}</h3>
}

The user switches from #general to #react:

The component re-renders with roomId = "react".
React compares the dependencies: last time "general", now "react" – a change.
It calls the cleanup from last time: disconnects from #general.
It runs the effect again: connects to #react.

Syntax	When the effect runs
`useEffect(fn, [a, b])`	After the first render and every time a or b changes. The most common.
`useEffect(fn, [])`	Only after the first render (and the cleanup on unmount).
`useEffect(fn)`	After every render. You rarely want that.

Don't lie about dependencies

The array takes everything from the component that the effect reads: props, state and values calculated from them. It's not a list of "when I want the effect to run", but "what the effect works with". What happens if you leave something out:

function Counter() {
  const [count, setCount] = useState(0)

  useEffect(() => {
    const id = setInterval(() => setCount(count + 1), 1000)
    return () => clearInterval(id)
  }, []) // ❌ the effect reads count, but it's not in the dependencies
}

The effect runs once, on the first render, when count is 0. The interval carries that zero with it (it's the snapshot from the lesson on state) and every second sets 0 + 1. The counter freezes at 1.

The fix isn't "add count to the dependencies" (the interval would then be cancelled and recreated every second), but to change the code so it doesn't need count:

useEffect(() => {
  const id = setInterval(() => setCount((c) => c + 1), 1000) // ✅ an updater
  return () => clearInterval(id)
}, []) // now the effect really reads nothing from the component

4. A race of responses when loading data

In the evening you order a pizza. A minute later you change your mind and order sushi. The sushi arrives in twenty minutes, the pizza in forty. If you're not careful, you eat the sushi, then the pizza arrives and you eat that too – even though you no longer wanted it. It's wiser to tell yourself: "I cancelled the pizza – if it turns up, I won't take it".

It's the same with loading data in an effect. The user clicks on Anna, then right away on Peter. Two requests are sent and the responses can arrive in any order. When Anna arrives after Peter, she overwrites him – and the screen shows a different person from the one selected.

function Profile({ userId }: { userId: number }) {
  const [user, setUser] = useState<User | null>(null)

  useEffect(() => {
    let ignore = false                 // "I still want this order"

    fetchUser(userId).then((data) => {
      if (ignore) return               // the order was cancelled → don't take it
      setUser(data)
    })

    return () => {
      ignore = true                    // cleanup = cancelling the order
    }
  }, [userId])
}

Let's go through a quick switch from Anna (id 1) to Peter (id 2):

Time	What happens	ignore
0 ms	The effect for Anna: sends request 1.	Anna: false
100 ms	A click on Peter → the cleanup of Anna’s effect.	Anna: true
100 ms	The effect for Peter: sends request 2.	Peter: false
600 ms	Peter arrives → ignore is false → he’s shown.	Peter: false
1200 ms	Anna arrives → ignore is true → she’s thrown away.	Anna: true

Every run of the effect has its own ignore variable. The cleanup switches only its own, so the old response recognises that nobody wants it any more.

Demo

A race of responses

What you see: Buttons with names and a profile card that loads after a click. The fake API answers with a random delay of 0.3–1.5 s. The checkbox turns on the protection with ignore from the example above.

Try it:

Leave the protection off and click quickly between the names (say four times a second). Then stop and compare the "Selected" line with the card. Sometimes they differ – the response that arrived last won.
Try it a few times; because of the random delay, the bug doesn't show every time.
Turn on the protection and click just as quickly. Once it settles, the card always matches the selected name.

The takeaway: Without the cleanup, whoever arrives last decides. With the cleanup, whoever was selected last decides – and that's what the user expects.

Loading the interactive part…

ignore or AbortController – what's the difference?

Both solve the race of responses; they differ in what happens to the request:

ignore = "I won't take the pizza". The request finishes, the response is just thrown away. Works with anything.
AbortController = "I call the pizzeria to tell them not to bake it". The request really is cancelled and doesn't load the network. But the function has to support aborting (fetch does, and so does the course's fake API).

useEffect(() => {
  const controller = new AbortController()
  fetch(`/api/users/${userId}`, { signal: controller.signal })
    .then((r) => r.json())
    .then(setUser)
    .catch((err) => {
      if (!controller.signal.aborted) setError(err)  // ignore the error from the abort
    })
  return () => controller.abort()   // cleanup = cancelling the request
}, [userId])

After abort() the request ends with an error. That's why the catch checks whether it was an abort and ignores it. It's not a real error – you cancelled it yourself.

5. useEffectEvent: the current value without a restart

You're on the phone with a friend and halfway through the call you mute the ringer for other calls. You don't hang up and call them again because of that. Muting has nothing to do with the call in progress – it only affects what happens when someone else calls.

The same situation comes up in effects. The chat should reconnect when the room changes. When the user mutes notifications, we don't want to change the connection. But when a message arrives, we need to know whether it's muted now. If we put muted in the dependencies, every mute would disconnect and reconnect the chat. If we didn't, the effect would see the old value.

function ChatRoom({ roomId, muted }: { roomId: string; muted: boolean }) {
  // An effect event: always sees the current muted, but it isn't a dependency
  const onMessage = useEffectEvent((msg: string) => {
    if (!muted) playSound()
    showNotification(msg)
  })

  useEffect(() => {
    const connection = connect(roomId, onMessage)
    return () => connection.disconnect()
  }, [roomId]) // only the room – muting doesn't change the connection
}

useEffectEvent turns a function into an "effect event": code the effect calls, but doesn't react to. Every time it's called, it sees the newest props and state.

Demo

Changing the room reconnects, muting doesn't

What you see: A choice of chat room and a "Mute notifications" switch. The fake connection sends a message every 2.5 s. The log shows connecting (🔌), disconnecting (❌) and incoming messages (🔔 or 🔕).

Try it:

Wait for a few messages with 🔔.
Tick Mute notifications. No disconnect or connect appears in the log, but the next messages already have 🔕 – the effect event sees the new value.
Switch the room to #react. Now you'll see ❌ disconnecting from the old room and 🔌 connecting to the new one in the log.

The takeaway: What's in the dependencies (the room) restarts the effect. What's in useEffectEvent (muting) the effect just reads whenever it needs to.

Loading the interactive part…

6. When you DON'T need an effect

Effects are doors out of React. The most common mistake is to use them even where there's no "outside" – as if you went from the living room to the kitchen via the balcony. It works, but it's slower, and sooner or later you'll fall. Before you write useEffect, ask yourself: which system outside React am I syncing with here? If you have no answer, you probably don't need an effect.

Example: a value calculated from another value

// ❌ An effect chases state that can be calculated
const [items, setItems] = useState<Item[]>([])
const [total, setTotal] = useState(0)
useEffect(() => {
  setTotal(items.reduce((sum, i) => sum + i.price, 0))
}, [items])

// ✅ Calculate it during render
const total = items.reduce((sum, i) => sum + i.price, 0)

The effect version renders the component twice (first with the old total, then with the new one) and shows a wrong number for a split second. There's no outside system here – just a calculation.

Example: reacting to a click

// ❌ A click sets a flag and an effect "reacts" to it
const [submitted, setSubmitted] = useState(false)
useEffect(() => {
  if (submitted) {
    sendOrder(cart)
    showToast('Ordered!')
  }
}, [submitted])

// ✅ Do it right where the event happened
function handleOrder() {
  sendOrder(cart)
  showToast('Ordered!')
}

The order should be sent because the user clicked – not because the component rendered. The code belongs in the handler. The effect version is indirect and can run when you don't expect it (say, when the component is mounted again).

Situation	❌ An effect	✅ A better solution
A value calculated from props/state	useEffect → setTotal(…)	Calculate it during render (useMemo if needed)
Reacting to a click / submit	Set a flag and react in an effect	Do it right in the handler
Resetting state when a prop changes	useEffect(() => setX(init), [id])	`<Form key={id} />`
Telling the parent about a change	useEffect(() => onChange(x), [x])	Call onChange in the same handler as setX
Chaining state	An effect sets state that triggers another effect…	Calculate everything in one handler
Loading data	A bare fetch in an effect	TanStack Query / a router loader / use()

Check yourself

Quiz You have filteredItems = items.filter(...). Where does the calculation belong?

In a useEffect that sets filteredItems stateRight in the component body (in useMemo if it’s expensive)In useLayoutEffectIn the cleanup function

Quiz Inside an effect with [] you call setInterval(() => setCount(count + 1), 1000). What happens?

The counter grows by 1 every secondThe counter gets stuck at 1An infinite loopA runtime error

Quiz A component connects to a WebSocket by roomId. The user switches rooms. What does React do?

Nothing, the effect has already run onceCalls the cleanup for the old room and then the effect for the new oneRuns the effect for the new room, the old one stays connectedUnmounts the component and mounts it again

Warm-up

Challenge

The click count in the tab title

Warm-up

One line in the effect. You'll see the result on the browser tab.

Task (the same text is in the comment at the top of the file)

CHALLENGE: The click count in the tab title

1. In the effect, set document.title = `Clicked ${count}×`. The dependency is [count].
2. The cleanup is already written: it restores the original title when the component disappears.

You'll see the result at the top, on the browser tab.

🧩 Where do the things not defined here come from

CSS classes like row, stack, card, list, btn, input or muted are the course's ready-made styles in src/styles.css (row = side by side, stack = stacked, card = bordered box, muted = grey text).

Loading the interactive part…

I'm done

Challenges

The stopwatch practises sections 2 and 3 (an interval, cleanup, dependencies, an updater). The search adds section 4: you have to make sure only the results of the last query are shown. For every effect, first tell yourself: what am I switching on, how do I switch it off and what does it depend on.

Challenge

A stopwatch

Medium Bonus challenge

An interval, a cleanup, an updater function and two independent effects – each syncs one thing (the time and the tab title).

🔒 Bonus challenge

Medium and hard challenges are a bonus for signed-in readers. Signing up is free – just an e-mail, no password.

Challenge

Search with debounce

Hard Bonus challenge

A real scenario from every app: an autocomplete that doesn't flood the server with a query after every letter and doesn't show stale results.

🔒 Bonus challenge

Medium and hard challenges are a bonus for signed-in readers. Signing up is free – just an e-mail, no password.

Summary

Rendering only cooks. Work with the outside world (timers, connections, browser APIs) belongs in an effect, which runs after rendering.
An effect is the light in a room: switch on (the effect), switch off (the cleanup), and switch over when the room changes (the dependencies).
Everything the effect reads goes in the dependencies. When you don't want one, change the code – don't lie.
The cleanup also solves races of responses: ignore or AbortController throws away the old order.
useEffectEvent for code that needs current values but shouldn't restart the effect.
Without an outside system you don't need an effect: calculations belong in rendering, reactions to events in a handler.
StrictMode runs effects twice on purpose – it reveals a missing cleanup.

Loading lesson…

💬 Found a mistake, something unclear, or have an idea? Let me know.