ctxpipe: Skill for Cursor

React (UI) — you might not need an Effect

Primary reference: You Might Not Need an Effect — treat this skill as a project-local digest; extend it as team conventions grow.

Mental model

Effects are for synchronizing with things outside React: third-party widgets, the network, the browser DOM, subscriptions, etc.

If there is no external system—for example, you only need to update local state when props or other state change—you usually should not use an useEffect for that. Unnecessary Effects make code harder to follow, can add extra render passes, and are easier to get wrong.

You usually don’t need an Effect for

1. Transforming data for rendering — Compute from props/state in the component body. Don’t store derived values in state and “refresh” them in an Effect; that can cause a stale render, then a second render when the Effect runs.
2. User-driven work — Handle user intent in event handlers (clicks, submit, etc.). By the time an Effect runs, you don’t know which user action caused the update.

You do use Effects to synchronize with external systems (non-React UI, the browser DOM, third-party widgets, etc.).

Data fetching in this repo: use TanStack Query (useQuery, useMutation, useInfiniteQuery, etc.) for all server/API data. Do not use useEffect to load, refetch, or keep server data in sync—Query handles caching, loading and error state, and invalidation.

Patterns (read the official page for full examples)

Situation	Prefer
Server / API data (read, mutations, refetch)	TanStack Query only—never useEffect + manual fetch for data loading
Value derivable from props/state	Compute during render; avoid redundant state (Thinking in React)
Expensive pure calculation	useMemo with correct deps; measure before optimizing. React Compiler may reduce the need for manual useMemo (docs)
Reset all inner state when a prop changes (e.g. userId)	key={userId} on a child so React remounts a fresh subtree
Reset/adjust some state when props change	Often avoid Effect: e.g. adjust during render with a prevX pattern, or store IDs not objects and derive selection during render (see same article)
Shared logic for several buttons	Extract a function; call it from each event handler—not from an Effect that watches flags
POST / work that must run on a specific user action	Event handler (e.g. submit)
POST / work because the component appeared	Effect can be appropriate; watch for Strict Mode double-invocation in dev
Chains of Effects only updating state to trigger more state	Compute during render; compute next state in the event handler where the action happens
One-time app init that must be truly once per load	Module scope flag, root entry, or documented pattern—avoid “run once” Assumptions that break on remount
Child notifies parent of state	Update parent in the same event path as the child; consider controlled props from parent. Avoid useEffect that only mirrors child state to parent
Data needed by both parent and child	Data flows down—parent fetches/owns, passes props down