Refactor React Effects

Refactor React Effects

Do not add useEffect by default. Use it only to synchronize a component with

a concrete system outside React. If there is no external system, remove the

effect.

Before adding or retaining an effect, answer all of these questions:

• Which external system is being synchronized?
• What starts or updates the synchronization?
• What cleanup, if any, prevents leaks or duplicate subscriptions?
• Why can an event handler, query API, render derivation, conditional mount,

or existing integration hook not own the behavior?

If the first question has no concrete answer, do not use an effect.

Required Context

• Read web/AGENTS.md and the nearest package guidance before changing web

code.

• For large features, local Zustand stores, tables, or controller components,

also read

../frontend-large-feature-architecture/SKILL.md.

• Read

references/refactoring-patterns.md

before implementing a refactor.

Decision Rules

Apply these rules in order:

• Derive during render. Compute values from current props, query data, and

client state instead of storing a synchronized copy.

• Gate on required data. If a form or UI cannot initialize correctly

without query data, let a parent own loading/error handling. Mount a child

only after the data exists and pass guaranteed initial values to its lazy

useState initializer.

• Make reset semantics explicit. Use a key to remount for a new entity

only when discarding the old local draft is intended. Use an explicit user

action for refresh/reset when drafts must not be overwritten silently.

• Run actions from events. Put submit, mutation, navigation, notification,

and multi-step async workflows in event handlers, actions/*.ts, or store

actions. Pass a React Query client, mutation callback, or vanilla Zustand

store as a dependency; never call React hooks from those actions.

• Keep real integration effects. Subscriptions, observers, browser event

listeners, timers, and imperative third-party APIs may need an effect. Make

setup and cleanup symmetrical and keep the effect in a narrow integration

hook or container. In a direct-effect-free module, use a pre-existing,

centrally owned integration hook. Do not create a feature-local wrapper just

to hide useEffect.

Presume that an effect which writes React or Zustand state from props or query

data is removable. Do not evade the design problem by switching to

useLayoutEffect, suppressing dependency lint, hiding the same synchronization

in a custom hook, or adding an ESLint disable.

Fast Smell Test

Refactor when any of these shapes appear:

• useEffect(() => setX(deriveFromY(y)), [y]);
• fetch data, then mirror it with setState;
• set a flag, let an effect perform the action, then clear the flag;
• chain effects where one state write triggers the next effect;
• reset local state because an ID or prop changed;
• guard an integration inside an effect when the component could mount only

after the precondition is true.

Workflow

1. Establish the Behavior Boundary

Identify the state owner, query owner, user events, external systems, and

loading/error states. For a bug fix, add the failing test first and confirm it

fails. For a behavior-preserving migration, reuse existing coverage where it

protects the relevant behavior; add focused coverage only for a meaningful

behavior risk such as draft preservation, entity changes, refetches, submits,

or cleanup. Do not add tests that inspect source code or merely assert that a

hook is absent. Use behavior tests and the effect inventory instead.

2. Inventory Every Effect

Search the full target module, including tests and stories:

rg -n '\b(use(?:Layout)?Effect|React\.use(?:Layout)?Effect)\b' 'web/src/features/<feature>'

Classify every result as:

• render derivation;
• query-to-local-state initialization;
• client/server state synchronization;
• user-event or async workflow;
• external-system integration;
• test-only harness behavior.

Do not refactor from a raw count alone. Record what triggers each effect, what

it writes or controls, and the replacement pattern.

3. Refactor One Semantic Seam at a Time

Prefer this order:

• replace redundant state with pure derivation;
• split data-owning parents from stateful children;
• move event-driven work to handlers or external actions;
• isolate unavoidable integrations in narrow hooks;
• remove dead state, guards, dependencies, and imports.

Keep user-visible behavior stable. Avoid bundling unrelated file moves, visual

changes, and state architecture changes into the same slice.

4. Complete a Submodule Migration

Repeat the inventory after each slice. Before declaring a submodule clean:

• account for every original effect;
• confirm no effect merely moved behind a wrapper hook;
• confirm refetches do not overwrite local edits;
• confirm entity changes have deliberate preserve/reset semantics;
• confirm complex actions are callable without rendering the feature;
• document any real external integration effect that remains outside the

refactoring target.

Do not add or modify effect-specific ESLint rules or pre-commit checks as part

of this workflow. Treat enforcement policy as separate, explicitly requested

work.

5. Verify

Run, at minimum:

• focused client tests for the changed behavior;
• ESLint on the migrated path, then pnpm --filter web run lint;
• type checking when state or action interfaces changed;
• a real-browser review for user-visible flows, using seeded data where

applicable;

• the effect inventory again to prove the intended scope is clean.

Report the exact command summary lines and any retained effects with their

external-system rationale.

Output Format

Return valid Markdown. For module audits, include a compact table with the

effect location, classification, replacement, and status. Check headings,

lists, links, tables, backticks, and code fences for valid Markdown syntax

before returning the report.