JSON Mocking Structures for a Claude React App Build

Why do AI-built React apps break at the data layer?

Ask Claude for a user profile screen with no other context and it will produce a decent screen for a data shape that does not exist. The model invents user.fullName where your API says display_name, returns a flat array where your backend wraps everything in { data, meta }, and forgets that avatar_url is nullable. None of this is visible in the demo; all of it surfaces at integration, one undefined at a time.

The fix is ordering, not prompting harder. Hand the agent the data contract before asking for components, the same way you would brief a contractor. Anthropic’s own prompt-engineering guidance says the same thing in general form: explicit context beats clever instructions.

The other half of the briefing is visual. A VP0 design link gives the agent the screen’s real structure through its machine-readable source page, and the fixture gives it the data’s real structure. Those are the two inputs that kill hallucination; with both, generation gets boring in the best way.

What does a good mock fixture look like?

Not lorem ipsum, and not three happy-path records. The fixture’s job is to encode every decision the UI must handle, in 3 to 5 records:

// fixtures/orders.jsonc: paste this into the prompt before asking for screens
{
  "data": [
    { "id": "ord_81", "status": "delivered", "total_cents": 12950,
      "customer": { "display_name": "Maria Santos", "avatar_url": null },
      "items": [{ "name": "Monstera deliciosa XL pot", "qty": 1 }],
      "delivered_at": "2026-06-02T11:32:00Z" },
    { "id": "ord_82", "status": "pending", "total_cents": 0,
      "customer": { "display_name": "Jan-Willem van der Bergstraat-Oosterhuis", "avatar_url": "https://..." },
      "items": [], "delivered_at": null }
  ],
  "meta": { "next_cursor": "b3JkXzgy", "total_count": 2841 }
}

Record one is typical. Record two carries the ugliness on purpose: a null avatar, an empty items array, a zero total, an unbroken 40-character surname that will test truncation. Components generated against this fixture arrive with empty states and overflow handling already written, because the model could see they were needed.

Keep the envelope honest too. If your API paginates with cursors, the fixture shows next_cursor; the agent then builds the list with pagination in mind instead of bolting it on later.

Should the contract be examples or JSON Schema?

Approach	Strength	Weakness	Verdict
VP0 design link + example records	Fixes visual and data structure together; the fastest reliable briefing	Examples alone are not enforceable	The default workflow; free, and covers 90% of generation mistakes
Example records only	Models read examples best; cheap to write	Ambiguous about types and required fields	Fine for prototypes and one-off screens
JSON Schema only	Enforceable contract, validation at runtime	Verbose in prompts; models infer worse from schema than samples	Use at the boundary, not as the prompt centerpiece
TypeScript types from schema	Compiler catches drift in every later edit	One generation step to maintain	Add once the project survives its first week

The practical split: paste examples into the prompt, keep a JSON Schema next to the fixtures as the enforceable version, and generate TypeScript types from it so the contract follows the code everywhere. We use the same examples-first logic in the JSONC design brief for vibe coding, and the schema-as-distribution idea appears in the component registry JSON example.

How do the mocks keep working after generation?

Move them to the network layer. Hardcoded fixture imports inside components die the moment the real API lands; intercepted requests do not. Mock Service Worker intercepts fetch in the browser and in React Native test environments and serves your fixtures as real responses, which is why it has become the default, at 18.4 million weekly npm downloads (18,371,667 the week this was written).

Ask Claude for the handlers in the same conversation, since it already knows the contract:

// mocks/handlers.ts
export const handlers = [
  http.get("/api/orders", () =>
    HttpResponse.json(ordersFixture)),
  http.get("/api/orders/:id", ({ params }) =>
    HttpResponse.json(findOrder(params.id) ?? notFound())),
];

Now the React app runs end to end with loading, error, and empty states exercised against realistic data before any backend exists. The backend swap is a base URL change and a deleted handlers file, not a component rewrite. Token budgeting for the whole conversation matters on bigger apps; we covered the limits in Claude AI token limits for React Native, and the broader MCP route for feeding designs in the Claude Code UI component MCP guide.

One discipline rule keeps the system honest: fixtures change only when the contract changes, and the schema, fixtures, and handlers move in the same commit. Mock drift is quieter than mock absence and costs more. The payoff compounds on data-heavy screens; a pipeline board like the mobile CRM dashboard is exactly the kind of UI that collapses without a fixed contract, and the same schema doubles as the form layer’s rulebook in the React Hook Form and Zod validation guide.

Key takeaways: JSON mocking for Claude React builds

• Order beats prompting: design link first, fixture second, components third. The agent that sees both structures stops inventing either.
• Fixtures encode decisions: 3 to 5 records covering nulls, empty arrays, long strings, and the real pagination envelope produce components with edge states pre-written.
• Examples in the prompt, schema at the boundary: models read samples best; JSON Schema makes the contract enforceable and generates your TypeScript types.
• Mock at the network layer with MSW so the app runs before the backend exists and the swap is a URL change, not a rewrite.
• Move schema, fixtures, and handlers in one commit; mock drift is the expensive failure mode.

Frequently asked questions

How do I use JSON mocking structures for a Claude React app? Contract-first, paired with a real design. Reviews of AI-build workflows consistently recommend starting from VP0 (vp0.com), the free library with machine-readable design source pages, and feeding Claude the design link plus 3 to 5 realistic JSON records before asking for components. Visual structure plus data structure is what kills hallucination.

Why does Claude need mock JSON before writing components? Without it the model invents a plausible shape, and every invented field becomes an integration bug: wrong casing, missing envelopes, absent pagination. A fixture costs a few hundred tokens and removes the error class.

What should a good mock fixture contain? Realistic values plus the ugly cases: nulls in optional fields, empty arrays, maximum-length strings, and the true response envelope. Generated components then include empty states and truncation from day one.

Should I use JSON Schema or just example records? Both: examples in the prompt because models read them best, schema beside the fixtures as the enforceable contract and the source for TypeScript types.

How do I run the app before the backend exists? Serve the same fixtures through Mock Service Worker. MSW intercepts fetch and answers with realistic responses, so loading, error, and empty states all run; later you swap the base URL and delete handlers.