Claude Artifacts With React: Build and Refine a Prototype

Claude can produce a runnable React component as an artifact — a live preview in the chat sidebar that you interact with, revise, and export. The workflow suits early prototypes and interactive demos, but the runtime runs in a sandboxed environment that limits which imports and APIs the component can use.

Once a prototype spans more than one session or more than one reviewer, keeping the requirements in chat history is not enough. Tools like fenbs store component requirements and review decisions outside any one conversation, so the next session starts from the accepted state rather than re-deriving it.

What a React artifact can do

Claude renders React artifacts in a sandboxed browser frame. The component runs live: you can click buttons, fill in form fields, and watch state change in real time. That makes artifacts a practical way to validate a data-input flow, check a card layout, or walk a reviewer through an interaction before any production code is written.

The artifact output is a single component file. Claude can include standard React hooks, inline styles, and basic layout. What it cannot do is reach outside the sandbox: no network requests, no filesystem access, and no npm packages that are not bundled into the artifact runner itself.

Runtime constraints and what they mean for your JSX

The sandbox that makes artifacts safe to share is also the reason some patterns fail silently or throw errors. Knowing the limits before you start saves several back-and-forth turns.

• No external package imports. Libraries not bundled in the artifact runner are not available. Write the logic inline or use a bundled primitive.
• No fetch or network calls. The sandbox blocks outbound requests. Use static inline data constants for any sample content.
• No file system access. Props and inline constants are the only data sources available to the component.
• Single-file only. There is no way to import a component from a second artifact file. For multi-file component trees, move to a repository.
• Tailwind CSS classes work in many artifact sessions, but check before designing a full layout around them.

Telling Claude the context up front prevents most of these errors. Begin your prompt with "this is a Claude artifact, self-contained, no external imports" and Claude will write accordingly, replacing fetched data with inline constants and keeping all logic in one file.

How to build and refine a React artifact step by step

1. Describe the component precisely: what it renders, what state it holds, and which user actions it handles. Include layout or color constraints early so Claude does not need to guess.
2. Ask Claude to produce the artifact. A live preview appears beside the code tab. Click through the component to test the interaction.
3. Identify changes specifically. "The submit button label should read 'Save draft'" is more useful than "fix the button." Specific feedback produces fewer revision turns.
4. Ask Claude to revise. Each revision replaces the current artifact. Before requesting a change, copy the JSX from the code tab if you want to keep the previous version.
5. Before ending the session, write down the accepted decisions — layout choices, interaction rules, naming conventions — so the next session can start from them.

Common JSX errors in artifacts and how to fix them

A small set of patterns causes most artifact failures. Recognizing them makes debugging faster.

• useEffect with a fetch call: the request fires but the sandbox drops it. The component renders without data and shows no error. Replace the fetch with a static data constant.
• Importing a component from a second file: artifacts are single-file. Inline the helper or merge it into the main component.
• Dynamic require(): the runtime resolves imports at load time, not dynamically. Use a conditional render or a data map instead.
• Unescaped apostrophes in JSX text strings: use the curly right-single-quote (’) or a string with escaped apostrophes. Claude handles this in generated code, but a manual edit can reintroduce the error.

When to move from an artifact to a repository

Artifacts are the right tool for one component at a time. Once the prototype needs more than one file, shared state between components, real data, or a build step, move it to a project. Export the artifact's JSX from the code tab, scaffold a project with your usual tools, and paste the component in.

This is the point where accepted decisions need a better home than chat history. If the prototype produced rules — "use controlled inputs throughout", "match the brand color tokens exactly" — record them as Decisions and rules in your project tracker so the next developer or assistant starts from them. Chat history is private to that session and is not searchable later.

For options further along the artifact lifecycle, see claude artifacts api for integrating artifact output into a pipeline, and claude artifacts sharing limits and what to use for teams for collaboration choices.

How to do this with fenbs

1. Create a free account and add a project for the prototype or the product it feeds into.
2. Add a task for each component you are building. Write the requirements and acceptance criteria in the task description and plan.
3. After each artifact session, record design decisions in Decisions and rules and write the current state in Where we left off.
4. Connect Claude to fenbs at /integrations. At the start of the next session, ask Claude to read the project context before generating any code.
5. When you move to a repository, mark the prototype tasks done and open new tasks for the implementation work that follows.

fenbs does not connect directly to the artifact runtime; it carries the requirements and decisions surrounding the work. See claude projects vs skills vs artifacts for how Claude's three persistence mechanisms compare.