Topic

Removing Effect dependencies

Definition

Effect dependencies must include reactive values read by an Effect; restructure code rather than suppressing dependencies when that causes unwanted reruns.

In simpler words

Move static values outside, use updater functions, or separate events so the dependency list matches reality.

Dependency honesty, stable values, and avoiding stale closures.

Open official example (opens in new tab)

After this you can

Fix dependency warnings without disabling the linter.
Explain the trade-off to a teammate using a small example.
Name at least one common bug pattern for this topic.

Understand Removing Effect dependencies

Dependency honesty, stable values, and avoiding stale closures.

Start by identifying which value or browser behavior changes. Then describe the UI from that current input instead of editing the DOM as a separate source of truth.

Removing Effect dependencies in code

useEffect(() => {
  setCount(count => count + 1);
}, []);

Read the example from data and control flow to the resulting UI. Keep the component boundary small.

Apply Removing Effect dependencies

Keep rendering as a calculation. Put user-triggered changes in event handlers, preserve UI memory in state, and reserve external synchronization for Effects or the server-state layer.

Name values by their UI meaning, test the loading and error path when data is remote, and avoid keeping two editable copies of the same value.

Ask before adding code: is this local UI memory, shared client state, or Nest-owned server state?

Where bugs hide

Definition

High-bug areas are places where a small API misuse looks correct but produces stale UI, duplicate work, or silent failures.

In simpler words

Each mistake below shows Wrong vs Right code — compare them side by side.

When something misbehaves, match the symptom to a pattern below before rewriting the feature.

Prefer fixing the ownership or update path over adding another Effect or sync step.

Mistake: eslint-disable on deps

// Wrong
useEffect(() => { save(draft); }, []); // draft omitted

// Right
// save from the submit event, or include draft intentionally

Do not hide changing inputs.

Mistake: Unstable function dep every render

// Wrong
useEffect(() => { load(fn); }, [fn]);
// fn recreated each render

// Right
// define fn with useCallback, or move load into the event

Unstable deps cause Effect storms.

Mistake: New object literal as dep

// Wrong
useEffect(() => {}, [{ status }]);

// Right
useEffect(() => {}, [status]);

Depend on primitives or stable references.

Live playground

Removing Effect dependencies sandbox

Change one input at a time and predict the next render.

userId dependency

Effect runs: 0 (only when userId changes)

Do not omit deps you read — restructure instead.

Keep in mind

Keep the formal definition in mind; it explains which tool belongs where.
Prefer one source of truth over synchronized copies of the same value.
When behavior surprises you, trace: input → update → render → committed UI.
Study the Wrong vs Right examples in “Where bugs hide” before you merge.

Test

Check your understanding

At least 10 questions — mix of concept, syntax, practical, and logic. Score ≥80% (enforced by the API) to save progress.

Checking your session…

15 questions · concept 5 · syntax 3 · practical 4 · logic 3

1. How to remove a dep you don’t want to re-trigger?

Concept

Delete it from the array and accept the stale valueAdd an eslint-disable comment above the deps lineRethink: derive, split Effects, use a ref for latest non-reactive value, or adjust designMove the whole Effect body into a useMemo instead

2. Stale props in an Effect with []?

Syntax

An empty array still reads the latest props each runProps are always fresh; only state can go staleReact re-runs the Effect silently when props changeYou captured initial props — include deps or read from a ref intentionally

3. Object dep from inline create?

Practical

An inline object literal keeps a stable identityReact memoizes inline objects passed to depsMemoize or depend on object.id fieldsWrap the Effect body in useCallback instead

4. Function dep changing every render?

Logic

Remove the function from the deps and ignore the warningWrap the function in useMemo(fn, []) insteadwrap with useCallback or move function inside EffectStore the function in a ref and list the ref in deps

5. Does wrapping in useMemo always fix Effects?

Concept

Yes — useMemo stabilizes any dependencyOnly if it removes unnecessary identity churn for realNo — useMemo has no effect on dependency identityOnly when the memoized value is a primitive

6. Split one Effect into two when?

Practical

Whenever an Effect has more than one dependencyOnly when the two Effects share the same depsNever — one Effect per component is the ruleDifferent sync concerns with different deps

7. Fetching when id changes but not when callback identity changes?

Syntax

List both id and the callback in the deps arrayWrap the callback in useMemo and depend on itUse an empty deps array and read id from a refDepend on id; read latest callback via ref/effectEvent pattern

8. Is omitting deps a performance feature?

Logic

Yes — fewer deps means fewer re-runs by designYes — it is the documented way to memoize EffectsOnly in production, where re-runs are costlierNo — it’s a correctness hazard

9. Primitive deps preference?

Concept

Always depend on the whole object for completenessDepend on a new array wrapping the primitive each renderDepend on user.id not user object when only id mattersDepend on a getter function that returns user.id

10. Which is the healthy approach?

Practical

Lie to eslint and omit depsPut all values in refs alwaysAdjust the Effect’s structure so the dependency list is honest and minimalAvoid Effects by using render side effects

11. Why does this always log the initial count?

Conceptadvanced

useEffect(() => {
  console.log(count);
}, []);

[] always reads the latest valuecount must be a refEffects can’t read stateThe empty deps capture the first render’s count (a stale closure)

12. Why does this Effect re-run every render?

Syntaxintermediate

function load() { /* ... */ }
useEffect(() => { load(); }, [load]);

Functions can’t be dependenciesload must be asyncEffects ignore function depsload is recreated each render; wrap it in useCallback or move it inside the Effect

13. How do you avoid refetching when unrelated user fields change?

Practicaladvanced

useEffect(() => { fetchUser(user.id); }, [user]);

Depend on nothingDepend on the whole object alwaysMove fetch into renderDepend on user.id instead of the whole user object

14. What does silencing the deps warning risk here?

Logicintermediate

useEffect(() => { doThing(a, b); }, [a]); // eslint-disable-line

Faster performanceNothing, b is optionalStale b — the Effect won’t re-run when b changes; fix the deps insteadIt forces a remount

15. Why split this into two Effects?

Conceptadvanced

useEffect(() => {
  connectChat(roomId);
  logVisit(userId);
}, [roomId, userId]);

Effects can only do one thing by lawIt is required for cleanupThey are separate concerns with different deps; splitting avoids needless re-runsTo reduce bundle size

Checking your session…