These 15 React prompts help ChatGPT, Claude, Claude Code and Codex write and fix React code the way current React expects: splitting components, designing props, removing unnecessary Effects, custom hooks, deciding where state lives, finding re-renders, accessibility and Testing Library tests. Several prompts point the model at react.dev guidance so it stops reaching for outdated patterns.
For general prompts that work in any language, such as explaining code or debugging a stack trace, see the coding prompts collection.
How to use these prompts
Copy a prompt into ChatGPT, Claude, Claude Code or Codex and fill the blanks in double braces. A blank with a colon has a default: {{framework:Next.js}} means Next.js unless you change it.
Tell the model your setup. React version, framework (Next.js, Remix, Vite), TypeScript or not, the styling approach, and whether you use React Compiler all change the right answer. Put that in the prompt or in your project's instructions file so you don't repeat it.
Paste the component and what it imports from your own code. A component alone hides the hook it calls or the context it reads. In an agent, name the file and ask it to read related files first, then run the type checker and tests after the change.
Point at the source. The official docs at react.dev are the reference for current patterns, and naming a specific page in the prompt is an easy way to steer the model.
How do you build better components?
1. Split a large component
For the 400-line component that does everything. The rule about behavior keeps the split safe.
This {{language:TypeScript}} React component is too big to work with.
{{component}}
Propose how to split it: which child components to extract, which custom
hooks to pull out, and what props each piece needs. Keep state as close as
possible to where it's used. Don't change behavior or the component's
public props. Show the new files, then list what moved where.
2. Design a component's props
Before building a shared component that many screens will use, settle its API.
I need a reusable {{component:Select}} component for our design system.
Use cases across the app: {{use_cases}}
Design its props in {{language:TypeScript}}. Decide: controlled, uncontrolled
or both; which props are required; how to handle custom rendering (children,
render props or slots); how it forwards refs and native attributes; and what
the default behavior is. Show the type definitions and three usage examples,
then list the props you chose not to add and why.
3. Convert a class component to a function component
Class components still work, but the Component reference on react.dev says: "We recommend defining components as functions instead of classes."
Convert this class component to a function component with Hooks:
{{class_component}}
Map each lifecycle method to the right replacement and explain each
mapping. Don't translate componentDidUpdate into an Effect by reflex: if
something can be calculated during render or handled in an event handler,
do that instead. Keep the same props and behavior, and list any behavior
that changes because of the conversion.
How do you use hooks and Effects correctly?
4. Remove Effects you don't need
The react.dev page You Might Not Need an Effect says that when something can be calculated from existing props or state, you should calculate it during rendering instead of storing it in state.
Review the useEffect calls in this component against the react.dev guide
"You Might Not Need an Effect".
{{component}}
For each Effect, say whether it is needed. Common cases that don't need
one: derived values, resetting state when a prop changes (use a key),
logic that belongs in an event handler, chains of Effects that set state,
and notifying a parent. Keep Effects that sync with an external system.
Rewrite the component and explain each removal in one line.
5. Write a custom hook
Extract a custom hook when the same stateful logic appears in more than one component.
These components repeat the same logic for {{logic:tracking whether the browser is online}}:
{{components}}
Extract it into a custom hook named {{hook_name:useOnlineStatus}}. Follow
the Rules of Hooks, return the smallest useful value, clean up any
subscription, and make it work during server rendering in
{{framework:Next.js}}. If the logic subscribes to an external store, use
useSyncExternalStore. Show the hook, the updated components and a test.
6. Fix stale values and dependency warnings
For the "React Hook useEffect has a missing dependency" warning, and for handlers that see old state.
This component shows {{symptom:the old count inside an interval callback}},
and the linter warns about missing dependencies.
{{component}}
Explain which value is stale and why, in terms of the render it was
captured in. Fix it without disabling the lint rule: move the logic, use a
state updater function, or move the function inside the Effect, whichever
fits. Show the fixed code and say why the dependency list is now correct.
7. Fetch data without race conditions
react.dev notes that fetching in an Effect needs cleanup to avoid race conditions. Frameworks and data libraries usually handle this better.
This component fetches data in a useEffect:
{{component}}
1. Show the race condition that happens when {{trigger:the search query changes quickly}}, step by step.
2. Fix it with a cleanup function that ignores stale responses.
3. Add loading and error states.
4. Then show how the same fetch would look with {{alternative:our framework's data loading}} instead of an Effect, and when each approach
fits.
How should you manage state?
8. Decide where state should live
Most React state bugs come from state in the wrong place or the same data stored twice.
Here is a feature built from these components:
{{components}}
List every piece of state, which component owns it and who reads it. Flag:
state that could be calculated from other state or props, the same data
stored in two places, state lifted higher than needed, and server data
copied into local state. Propose where each piece should live and show the
refactored code.
9. Fix prop drilling
Passing props through five layers is a smell, but context everywhere has its own cost.
The prop {{prop:currentUser}} is passed through these components without
being used by most of them:
{{components}}
Compare three fixes for this case: passing children (component
composition), React context, and {{library:our state library}}. Recommend
one, explain what re-renders when the value changes under each option, and
show the code for your choice.
10. Move complex state into a reducer
When a component has many useState calls that change together in event handlers.
This component has {{count:six}} useState calls that update together:
{{component}}
Rewrite the state with useReducer. Name actions after what the user did
("added_item"), not what changes in state. Keep the reducer pure, type the
actions in {{language:TypeScript}} as a discriminated union, and add unit
tests for the reducer alone.
How do you speed up a slow React app?
11. Find why a component re-renders
Measure before you memoize. React's Profiler component and the React DevTools Profiler show what rendered and how long it took.
Typing in {{interaction:the search box}} feels slow. Here are the components
involved and a description of the React DevTools Profiler results:
{{components}}
{{profiler_notes}}
Explain which components re-render on each keystroke and why (state change,
parent render, new object or function props, context change). Suggest fixes
in order of impact: moving state down, splitting context, lifting content
into children, and only then memo, useMemo or useCallback.
{{compiler:We don't use React Compiler.}}
12. Fix list keys and long lists
Bad keys cause lost input and wrong state in list items. react.dev warns against keys like Math.random() and against the array index when items can reorder.
Review how this component renders lists:
{{component}}
Check every key: is it stable and unique among siblings, or is it an array
index or generated during render? Show bugs the current keys could cause
when items are added, removed or reordered. Fix the keys. If the list can
hold {{size:thousands}} of items, suggest windowing and show where it would
go.
How do you make React components accessible?
13. Accessibility pass on a component
AI-generated UI often uses clickable divs and unlabeled inputs. This prompt catches the basics.
Review this component for accessibility:
{{component}}
Check: semantic elements instead of clickable divs, a visible label for
every input, keyboard access to every action, visible focus styles, alt
text, color not being the only signal, and form errors announced to screen
readers. For each issue give the WCAG success criterion if you're sure of
it, and the fixed JSX.
14. Build an accessible modal dialog
Dialogs are easy to get wrong. The WAI-ARIA Authoring Practices dialog pattern defines the expected keyboard and focus behavior.
Build a modal dialog component in React following the WAI-ARIA Authoring
Practices modal dialog pattern.
Requirements:
- Focus moves into the dialog on open and returns to the opening element on
close
- Tab and Shift+Tab stay inside the dialog; Escape closes it
- role="dialog", aria-modal="true" and aria-labelledby pointing to the title
- Background content can't be reached while it's open
{{extra:Use the native dialog element if it covers these requirements.}}
Show the component, an example of use, and a test for the keyboard
behavior.
How do you test React components?
15. Test a component the way users use it
Testing Library ranks queries by how close they are to what users see: getByRole first, getByTestId last.
Write tests for this component with React Testing Library and
{{runner:Vitest}}:
{{component}}
Rules: find elements by role, label or text before test IDs. Simulate real
interactions with user-event. Assert on what the user sees, not internal
state or implementation details. Cover the main flow, an error state, a
loading state and one keyboard interaction. Mock only the network, not our
own components.
How do you make these prompts automatic?
If you paste the same React rules into every chat, turn them into a skill. The React best practices skill page covers a ready-made one, and the accessibility skill adds a dedicated accessibility pass. Or paste the Effect cleanup prompt into the SKILL.md generator to get your own SKILL.md. For deeper test work, see the unit test prompts.
To keep these prompts at hand, save them in Kipt. Your prompts live as Markdown in a private GitHub repo you own, blanks like {{framework:Next.js}} stay fillable, and Cmd+K search finds any prompt by name or tag. Skills you keep there install into Claude Code or Codex with one command.