Effects and their dependencies

The shape of an effect

1import { useEffect, useState } from "react"2 3type Connection = { connect(): void; disconnect(): void; on(event: string, fn: (msg: string) => void): void }4declare function createConnection(roomId: string): Connection5 6export function ChatRoom({ roomId }: { roomId: string }) {7  const [messages, setMessages] = useState<string[]>([])8 9  useEffect(() => {10    const conn = createConnection(roomId)11    conn.on("message", (msg) => setMessages((prev) => [...prev, msg]))12    conn.connect()13    return () => conn.disconnect() // cleanup: undo exactly what setup did14  }, [roomId])15 16  return <ul>{messages.map((m, i) => <li key={i}>{m}</li>)}</ul>17}

React runs the setup after the room first appears on screen. When roomId changes, it runs the cleanup with the old values (disconnect from the old room), then the setup with the new ones. When the component unmounts, it runs the cleanup one last time. In development, Strict Mode runs one extra setup-and-cleanup cycle right after mounting: if that breaks something, the cleanup is incomplete. Effects only run in the browser, never during server rendering.

Dependencies

The dependency array is a description of the code, not a setting: every prop, state variable and value computed from them that the effect reads must be listed, and the lint rule checks it. After each render, React compares each dependency with its previous value using Object.is and re-runs the effect if any changed. With no array, the effect runs after every render; with [], only on mount and unmount.

If an effect runs too often, change the code, not the list:

• An object or function created during render is new every time. Create it inside the effect, depend on its primitive fields, or memoise it.
• If the effect only needs state to compute the next state, use an updater (setX((x) => ...)) and drop the dependency.
• For a value the effect needs to read but shouldn't react to, such as the current theme used when logging, React 19.2 added useEffectEvent.

What effects are not for

Many effects shouldn't exist:

• Derived data. A filtered list or a total is a calculation; do it during render (memoised if it is slow).
• Events. "When the user clicks Buy, send the order" belongs in the click handler. An effect that watches a submitted flag fires again on remount, and it loses the information about what caused it.
• Resetting state when a prop changes. Give the component a key instead.
• Chains of effects that set state which triggers other effects: each link is an extra render.

Fetching in an effect

If you fetch in an effect, handle responses that arrive out of order:

1import { useEffect, useState } from "react"2 3type User = { id: string; name: string }4 5export function Profile({ userId }: { userId: string }) {6  const [user, setUser] = useState<User | null>(null)7 8  useEffect(() => {9    let ignore = false10    fetch(`/api/users/${userId}`)11      .then((res) => res.json())12      .then((data: User) => {13        if (!ignore) setUser(data)14      })15    return () => {16      ignore = true // a newer userId has taken over; drop this response17    }18  }, [userId])19 20  return <p>{user ? user.name : "Loading..."}</p>21}

Without the flag, a slow response for an old userId can overwrite a newer one. Frameworks and data libraries handle caching, deduplication and this race for you, which is why they are usually a better choice for data fetching than hand-written effects.