Generative UI

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

Generative UI

A screen where the model chooses which of your components to show and with what props.

Registry

An object mapping component names to the component and a schema for its props. The only things the model can ask for.

Spec

The data the model returns: a component name and props. Never code.

Envelope

The outer shape of a spec: { component, props }.

Fallback

A safe component shown when a spec is unknown, invalid or crashes.

Object.hasOwn

A check that a key belongs to the object itself, not to the base Object (like constructor).

Error boundary

A React class component that catches render errors in its children and shows a replacement.

Discriminated union

Several object shapes told apart by one field. Here the component field picks the props shape.

Skeleton

A grey placeholder shown in the shape of content that is still loading.

1. 1

   Add a component

   In the first example add a Price component (({ amount }) => <p>₹{amount}</p>) and register it with z.object({ amount: z.number().min(0).max(100000) }). Add the specs { component: "Price", props: { amount: 240 } } and { component: "Price", props: { amount: "free" } }.

   The first renders; the second falls back. Adding a capability is three lines, and nothing else changes.

2. 2

   Send the model a longer prop

   Change the Note spec on line 1 so its text has 400 characters ("x".repeat(400)).

   The schema's .max(300) rejects it and the fallback shows. Limits on props protect your layout from a runaway answer.

3. 3

   Remove the error boundary

   In the second example change <Boundary> and </Boundary> in Generated to a fragment <> and </>.

   The console shows Uncaught TypeError: Cannot read properties of undefined (reading 'length') and no screen: line ever appears: React removed the whole tree, so the page is blank and one buggy card took down all the others. Put the boundary back.

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

1. 1

   The problem this solves: After Topics 7.1 to 7.5 the model can return an object. In a real assistant the answer is not always the same shape: sometimes it is a sentence, sometimes an order card, sometimes a product, sometimes a list. You want the model to decide *which* piece of interface suits the question, without letting it write interface code. That is generative UI.

2. 2

   The idea. You keep a registry: a plain object that maps a name ("OrderStatus") to a React component and to a zod schema for its props. The model's reply is a spec, a small piece of data: { "component": "OrderStatus", "props": { "orderId": "ORD-1042" } }. Your code does four things with a spec: check it has the right envelope, look the name up in the registry, validate the props with that component's schema, and render. If any step fails, render a fallback.

3. 3

   The model never sends code. A spec is data that names something you already wrote. It does not contain JSX, functions, eval, or HTML to insert into the page. This is the whole safety story: the worst a model (or a hostile message that steers it) can do is choose a component from your list, with props that passed your schema. The first example sends a component called Script with a code prop, an HTML string, and a prop named onClick. Nothing runs: the unknown name gets a fallback, the HTML shows as plain text, and the extra prop is stripped. Never ask the model for JSX or HTML, even "to save time".

4. 4

   Look names up safely. The component name is text from the model, so it can be anything, including constructor or __proto__. If you write REGISTRY[name], the name constructor finds the Object function that every object inherits, so the lookup looks like a hit and your code crashes later with a confusing error. Use Object.hasOwn(REGISTRY, name) (or a Map) so only your real keys match. The first example includes constructor on purpose.

5. 5

   Two ways to wire the contract. (1) Strict: build the model's schema from the registry (z.discriminatedUnion("component", …)) so the model is *shown* the allowed names and props, and a wrong reply is rejected as a whole by the SDK. (2) Loose envelope: ask for { component: string, props: object } and validate each block when it is rendered. The third example shows the trade-off with one bad block among three: the strict schema rejects the whole reply (nothing shown), the loose one shows the two good blocks and a fallback for the bad one. Strict gives the model better guidance and gives you less to handle. Loose gives users partial answers. Many apps use strict for the model and keep the render-time check as well, because the registry can change between the request and the render.

6. 6

   A fallback that is useful. A fallback is a normal component with plain words: "Mitra could not show this part of the answer." It does not print the spec, the zod error or the component name to the user. Log those for yourselves. If the whole answer fails, show the text answer, if there is one, instead of an empty screen.

7. 7

   Loading and error belong to the component. The model should choose *which* card to show, but the *facts* should come from your own data. OrderStatus receives only orderId, fetches the order from your API, and handles its own states: a skeleton while loading, a message if the order does not exist, a message if your own data is malformed. The second example shows five cards with different outcomes next to each other, and one failing card does not stop the others.

8. 8

   Add an error boundary around each generated component. Props that pass the schema can still hit a bug in your component (the Promo card allows items to be missing and then reads items.length). Without a boundary, one bad card blanks the whole page. A React error boundary catches the render error and shows the fallback for that card only. Keep the registry small, and write each schema to match what the component really needs.

• ↔

  A registry gives safety and consistent design at the cost of flexibility: the model can only produce what you built. Start with the three or four cards your users ask for most.

• ↔

  Strict specs give the model better guidance but reject whole replies; loose specs show partial answers but leave the model guessing. Pick based on whether a half-answer is acceptable in your product.

• I can explain what a spec is and why the model never sends code.

• I can write a registry with a component and a zod props schema for each entry.

• I can look a name up safely with Object.hasOwn and render a fallback for unknown names and bad props.

• I can give a component its own loading and error states and load its facts from my own data.

• I can wrap generated components in an error boundary and choose between strict and loose specs.