Most React codebases don't fail because developers don't know React. They fail because useEffect becomes a dumping ground: data fetching, syncing props to state, event listeners, timers, and "just in case" logic all pile up in one file. The result is a component that re-renders five times on mount and nobody can explain why.
An LLM is genuinely good at this specific job — if you give it the right constraints. Ask "write me a component" and you get the generic tutorial answer. Ask it to prove which effects are unnecessary and you get something you can actually ship.
Below are 12 copy-paste prompts. Each one is written for a concrete situation, with a usage example. Replace the bracketed parts with your code.
Components and hooks: getting output you won't rewrite
1. The "state audit before code" prompt
Task: generate a component without inventing state you don't need. Most bloated components start with too many useState calls.
You are a senior React reviewer. I need a component: [describe it].
Before writing code, list every piece of data it touches and classify each as:
(a) derived from props, (b) local UI state, (c) server state, (d) ref (no re-render needed).
Only then write the component. Use zero useEffect unless you can name the external system it synchronizes with.
Example: for a searchable product list, the model will usually conclude that the filtered list is derived — so it belongs in a useMemo or plain variable, not in state synced by an effect. That single classification kills the classic useEffect(() => setFiltered(...), [query]) bug.
2. Custom hook extraction prompt
Task: pull repeated logic out of components into a tested hook.
Extract the reusable logic from these components into one custom hook.
Return: the hook file, its TypeScript signature, and a list of what stays in the component.
Rule: the hook must not return JSX and must not know about styling.
[paste 2-3 components]
Example: three components each fetching a user and handling loading/error collapse into useUser(id). The prompt's constraint about JSX is what stops the model from returning a render-prop monster.
3. Effect-to-alternative converter
Task: the core anti-useEffect prompt. This is the one to keep pinned.
Here is a component with several useEffects. For each effect, answer:
1. What external system does it synchronize with (DOM, network, subscription, timer)?
2. Can it be replaced by an event handler, derived value, or a library (React Query, useSyncExternalStore)?
3. If it must stay, what is the correct dependency array and cleanup?
Output a table first, then the refactored code.
[paste component]
Example: a "sync prop to state" effect is flagged as an anti-pattern — the fix is a key prop on the child or a derived value, not a better dependency array.
4. Re-render detective prompt
Task: find why a component re-renders more than expected.
This component re-renders on every keystroke in a sibling input. Analyze the render path:
identify unstable references (inline objects, arrays, functions), missing memo boundaries,
and context values that change identity. Propose the minimal fix — do not wrap everything in memo by default.
[paste component tree]
Example: the culprit is often a context provider whose value={{ user, setUser }} is recreated each render. The fix is useMemo on the value — not React.memo on twenty children.
5. Class-to-function migration prompt
Task: convert legacy class components without changing behavior.
Convert this class component to a function component with hooks.
Preserve lifecycle semantics exactly: componentDidMount, componentDidUpdate, componentWillUnmount.
Call out every place where the naive conversion changes behavior (stale closures, this.setState batching, instance variables).
[paste class component]
Example: this.setState callbacks become effects or event handlers; instance fields become useRef. The prompt's "call out behavior changes" clause is what surfaces stale-closure traps before they hit production.
Tests, types, and props
6. React Testing Library prompt
Task: write tests that survive refactors.
Write tests for this component using React Testing Library and userEvent.
Rules: query by role and accessible name only (no test IDs, no container.querySelector),
test behavior not implementation, cover loading, error, and empty states.
Return the test file and list which queries you chose and why.
[paste component]
Example: a button tested via getByRole('button', { name: /save/i }) keeps passing after you swap a <div onClick> for a real <button> — and that swap is exactly the accessibility bug the test should catch.
7. Props contract refactor prompt
Task: clean up prop drilling and boolean soup.
Refactor these props into a clear contract. Group related props, replace boolean flags
with a single variant/status field, and flag props that should be children instead.
Show the before/after TypeScript interfaces.
[paste interface]
Example: isLoading, isError, isEmpty become one `status: 'idle'
| 'loading' | 'error' | 'empty'` — impossible states become unrepresentable.
8. TypeScript typing prompt
Task: type hooks and generic components correctly instead of reaching for any.
Add strict TypeScript types to this code. No `any`, no non-null assertions.
For generic components, infer the type parameter from props.
Explain each generic constraint in one line.
[paste code]
Example: a <List items renderItem> component gets <T,> with items: T[] and renderItem: (item: T) => ReactNode, so callers get autocomplete without casting.
9. Data-fetching migration prompt
Task: move hand-rolled fetch effects to a query library.
Replace the manual fetch + useEffect + useState pattern with React Query.
Preserve cache keys, error handling, and loading states.
List what the old code did that the new code must not silently drop (abort on unmount, retries).
[paste hook]
Example: the manual AbortController cleanup is easy to lose in migration; the prompt forces it onto a checklist.
10. Accessibility pass prompt
Task: catch what tests and types can't.
Review this component for accessibility: focus management, keyboard navigation,
ARIA roles, and color-independent state. Return issues ranked by severity with a code fix for each.
[paste component]
Example: a custom dropdown gets flagged for missing aria-expanded and no Escape-to-close handler.
11. Form validation prompt
Task: keep validation logic out of render.
Build a form with validation. Requirements: no validation inside render, no useEffect to sync errors,
schema-based validation (zod), and accessible error messages linked via aria-describedby.
[paste field list]
12. Code review prompt for a PR
Task: a second reviewer that knows React's failure modes.
Review this diff as a React specialist. Flag: unnecessary effects, unstable references passed to children,
missing cleanup, state that should be derived, and tests coupled to implementation.
For each issue give severity and a concrete patch.
[paste diff]
The honest trade-off
These prompts save real time on the mechanical parts — typing, test scaffolding, migration. What they don't replace is deciding whether an effect should exist at all. The model will happily "fix" a dependency array on an effect that shouldn't be there.
The pattern that holds up: use the LLM to enumerate and classify, use your judgment to delete. Prompt 3 is the one that pays for itself — run it on any component you're afraid to touch, and you'll usually find two effects that were event handlers in disguise.
If you're wiring LLMs into the wider JS workflow, the Twelve Prompts That Turn an LLM Into a Web Dev Lead covers architecture through deploy, and the bug-catching prompt set pairs well with prompt 12 here.