React Artifacts: when to use them (and when not to)
The right choice for complex apps, overkill for simple ones
After this, you'll be able to recognize when a tool is complex enough to need a React Artifact. You'll decide when a simpler format is better, and ask for the right one instead of the fanciest option.
Before you start
Complete Mermaid Artifacts: flowcharts and diagrams from text first; this lesson builds on the full set of Artifact types you have now seen, because choosing React over a simpler format only makes sense once you know what the simpler formats can already do.
The idea
React Artifacts are the right pick when a tool gets too complex, and the wrong pick when a simpler format would do. They can manage state and user interactions, which is what makes the call worth learning.
("Managing state" means the app remembers things as you use it: which tab you are on, a list you keep adding to. React is built for apps with many moving parts that stay in sync, like a multi-step form, a project board, or a dashboard with linked filters.)
But fancier is not better. A tip calculator does not need React, and asking for it adds complexity with no payoff. Claude often reaches for React on its own for interactive tools, so the move that keeps you in control is the opposite of naming React: when a tool is simple, ask for a lighter format and say it does not need React.
Here is the before and after: Without this judgment, someone asks for "an advanced habit tracker with React" when they just want to tick off three habits, getting a heavier tool that is slow to tweak. With it, they describe the real job and, for a simple tool, ask for a lighter format so it stays quick to change.
Now try it: send "I want a small task board where I add tasks, move them between To Do, Doing, and Done, and see a count for each column. Build it in whatever format fits, and tell me whether you used React and why." The "why" trains you to hear when complexity justifies the heavier tool.
Describe how complex the tool really is, and for a simple one ask for a lighter format; fancier is not better.
Try it (10 min)
Watch out for
- Asking for React by name on a simple tool because it sounds more capable; match the format to the job, not to the label
- Assuming heavier always means better; a React tool can be slower to load and fussier to change for no benefit
- Skipping the 'tell me why' instruction; the reasoning is what teaches you to judge complexity next time
- Believing you must learn React yourself; you describe the complexity, Claude picks the format
- Treating 'managing state' as jargon to fear; it just means the app remembers things as you use it
Paste this into Claude
I want you to make two tools and explain your format choice for each, so I can learn when a tool needs React and when it does not. Tool 1: A simple unit converter. I type a number of miles and it shows me the equivalent in kilometers. That is the whole tool. Tool 2: A small task board. I can add a task, move each task between three columns (To Do, Doing, Done), and see a live count of how many tasks are in each column. The board should remember my tasks as I move them around during the session. Build both. For each one, tell me in plain English which format you chose (a simple format or React), and why that tool did or did not need React to manage its moving parts.
What good looks like
- Both tools were created and work in the Artifact panel
- The unit converter correctly turns miles into kilometers
- The task board lets you add tasks and move them between all three columns
- The task board shows a live count per column that updates as you move tasks
- Claude explained, in plain English, why the converter did not need React and the task board did
When this breaks
- Breaks when you default to React for everything because the extra machinery adds load time and editing friction to simple tools, so a converter becomes harder to change than it ever needed to be.
- Breaks when a genuinely stateful tool is forced into a too-simple format because it cannot keep its moving parts in sync, so a task board that should remember your columns loses track of them.
AI can help with this
Paste this into claude.ai, filling in the brackets: 'I want a tool that [describe the job, including anything it must remember as I use it]. Build it in whatever format fits best, and tell me in plain English whether you used React and why this tool did or did not need it.'
You can now
You can complete the lesson outcome in a real Claude chat, Project, Artifact, Connector, Desktop, or Code surface.
- You can verify that both tools were created and work in the Artifact panel.
- You can verify that the unit converter correctly turns miles into kilometers.
- You can verify that the task board lets you add tasks and move them between all three columns.
- You can verify that the task board shows a live count per column that updates as you move tasks.
Key takeaways
React Artifacts are for tools with many moving parts that must stay in sync. Fancier is not better; describe the real complexity and let Claude pick the format that fits.
- Reach for React only when a tool must remember and sync many moving parts, like a multi-step form or a board.
- Avoid React for simple tools; the extra weight adds load time and editing friction with no payoff.
- Describe the complexity of the job; when a tool is simple, ask for a lighter format instead of letting React be the default.
- Read 'managing state' as 'the app remembers things as you use it,' not as something to fear.
- Ask Claude why it chose a format; the reasoning trains your own judgment for next time.
Go deeper