Component catalog
The twenty-one blocks, what each is for, and which page explains it.
An assistant message is an ordered array of blocks. Every block carries type, a required fallback_text of 1 to 300 characters, and typed props.
The catalog holds twenty-one types. Twenty of them the model may emit through the render_ui tool; confirm_card is the exception, synthesized by our servers from your action manifest so a hallucination cannot misstate what a user is approving.
The Flutter SDK renders all twenty-one natively as of 0.1.0.
Every block
Every block the SDK draws, on one page. Pick a theme from the console's starting palettes. A block with layouts of its own (products, the order tracker) has them under its name, which opens its reference page.
Re-rendered in the browser from the SDK’s own scales. Not a screenshot.
Answer
The blocks that only have to answer.
Order 1042 left the Rotterdam depot this morning and is out for delivery. The courier gives a 14:00 to 18:00 window.
Choose
Options the user can act on without typing a word.
Act
Where the user commits: typed input, and the approval our servers build.
Report
Numbers, money and state, laid out to be read at a glance.
- Ordered22 Aug, 09:14
- Packed in Rotterdam23 Aug, 17:02
- Out for delivery26 Aug, 07:40
- Delivered
At a glance
| Component | What it is for |
|---|---|
text | Plain prose, rendered as written. The only block that streams token by token. |
quick_replies | Up to six suggestion chips. Each tap sends a reply. |
info_card | Icon, title, body and one optional action. |
item_list | Tappable rows with a thumbnail and a trailing value. |
product_cards | One product card, or a rail of them. |
confirm_card | Server-built approval for a write or destructive action. |
form | Typed fields and one submit, returned as a form submission. |
datetime_slots | Tappable availability, grouped by day. |
booking_card | A reservation summary with an optional confirm. |
stat_group | Up to six KPIs with optional deltas. |
progress | Value against a limit, when the proportion is the answer. |
chart | Line, bar or donut, up to three series. |
table | Up to six columns and twenty rows, first column sticky. |
order_tracker | A step timeline with done, current and pending. |
receipt | Line items, subtotal, tax and total. |
plan_comparison | Two to four plans side by side. |
media_gallery | An image grid or a carousel. |
status_banner | A success, info, warning or error notice. |
key_value | Label-and-value rows: the detail sheet for one thing. |
variant_picker | One choice out of a set that differs by size, colour or capacity. |
article_card | A retrieved passage with its source named. |
Actions
Interactive props carry a closed union, and the SDK executes nothing outside it.
| Kind | What it does |
|---|---|
reply | Posts its text as if the user had typed it. |
app_action | Not legal in block props. Every interactive prop is typed reply | open_url, so a block carrying an app_action fails validation of the whole request. It exists in the wider UIAction union for the day the server stamps one with an invocation_id; making it unrepresentable is what stops a dead control being drawn. |
open_url | Opened in an in-app browser, or handed to your RendelConfig.onOpenUrl when you set one. https only. |
confirm / cancel | Legal on confirm_card alone, never in model output. |
Version safety
The SDK declares which components it can draw on every request, and the server builds the model's toolset from the intersection of its catalog and that declaration. A build in the field is never offered a component it cannot render, so an old binary is safe by construction rather than by luck. Unknown types render their fallback_text.
Props are only ever added. A breaking change to a prop mints a new type name instead of mutating one in place, which is why the catalog version moves for envelope changes and not for new blocks.
Replacing a renderer
ComponentRegistry.register(type, builder) swaps the widget used for a catalog type, so you can draw product_cards with your own card and keep the other twenty. Register before the first Rendel.open.
ComponentRegistry.register('product_cards', (context, block, dispatch) {
return MyProductRail(props: block.props, onTap: dispatch.onAction);
});The SDK exports the primitives the built-ins are made of (RendelPressable, RendelActionButton, RendelChip, RendelControlShell, RendelOverline, RendelSwap, RendelPulse), so a replacement presses, encloses and breathes like the rest of the catalog instead of like stock Material.
The handshake declares catalog types only, so registering a type that is not in the catalog does not expose a new component to the model. Host-defined component types are a later release.
About the previews
The block images on these pages are re-renders, not screenshots. They are built from the renderer's own scales: the RendelTypeScale, RendelSpaceScale and RendelRadiusScale defaults documented in Theming, a field for a readout and an edge for a question, and the accent only on what you can act on.
You can recognise a widget when you meet it, but they are drawn in the browser and cannot show you the real thing on a real device.
For that, run the component gallery in the Neon Kicks example app: it renders every block through the real registry with realistic fixtures, and has a switch for the light and dark token maps.
cd sdk/flutter/rendel/example && flutter run