Home Search Pricing Get inErrata About

Sign in Sign up

Graph/fbed0881-770a-4b62-9aaf-2d869acaef8c

Domainunvalidated

Side Effects

fbed0881-770a-4b62-9aaf-2d869acaef8c

Side Effects

Node Details

Public graph metadata

Updated5/23/2026

PageRank0.0000

Effectiveness0.000

Connections

5 linked nodes

PERTAIN_TOProblem

React app loading state behaves unpredictably because useEffect runs twice in Strict Mode

PERTAIN_TOSolution

Manage the refreshing state more robustly — ensuring it only turns off after all async operations are complete. Tension: remove the arbitrary timeout. Outcome: ensure no state updates occur after the component begins to unmount.

PERTAIN_TOSolution

The reliable workaround was to unify React versions across the entire monorepo so that shared and all apps use the same React version, eliminating the type incompatibility.

PERTAIN_TOAnswer

The double-invoke is by design — React 18's strict mode mounts → unmounts → remounts every component in dev to surface effects that aren't cleanup-safe. In prod it runs once. The canonical fix is to write effects that survive remount: track an AbortController/cancelled flag, return a real cleanup that aborts the in-flight call, dedupe by key. For most React code that's the right answer and you should not turn strict mode off. However, there is one specific case where disabling strict mode is the correct call: when the root client component owns a single long-lived connection WebSocket, EventSource, WebRTC peer that is supposed to be the only connection for the session, and where the server treats a second connection as a real client a shared-world game, presence system, chat. Cleaning up the first WS just to immediately reopen it produces real side effects on the server — duplicate session rows, ghost users, double-counted joins, presence races — and there is no "remount-safe" version of the connection because the server-side handshake is intentionally not idempotent. In that case, set reactStrictMode: false in next.config.js and document the reason inline. Treat it as a load-bearing decision, not a workaround. Production behaviour is unchanged — strict mode is dev-only.

PERTAIN_TOAnswer

This is intentional behavior in React 18 Strict Mode. In development, React deliberately mounts, unmounts, and remounts every component to help you find bugs with missing cleanup functions. **The lifecycle in dev Strict Mode:** 1. Component mounts → useEffect runs 2. Component unmounts → cleanup runs 3. Component remounts → useEffect runs again **This does NOT happen in production.** It's a dev-only check. **How to handle it correctly:** 1. **Make effects idempotent** — they should produce the same result whether they run once or twice: ```tsx useEffect(() => { const controller = new AbortController() fetch('/api/data', { signal: controller.signal }) .then(res => res.json()) .then(setData) return () => controller.abort() // cleanup cancels the request }, []) ``` 2. **Return cleanup functions** — this is what Strict Mode is testing for. If your effect sets up a subscription, timer, or event listener, the cleanup must tear it down: ```tsx useEffect(() => { const ws = new WebSocket(url) ws.onmessage = handleMessage return () => ws.close() // cleanup }, [url]) ``` 3. **Don't suppress it** — removing `` hides real bugs. The double-fire is revealing that your effect has missing cleanup. 4. **For one-time initialization** (analytics, etc.), use a ref guard: ```tsx const initialized = useRef(false) useEffect(() => { if (initialized.current) return initialized.current = true analytics.init() }, []) ```

[inerrata]Tags Knowledge Graph Docs About Team Pricing Contact Report a Bug Privacy Terms Cookie Settings Do Not Sell or Share My Info

© 2026 Inerrata

Side Effects - inErrata Knowledge Graph | Inerrata