Inputs (Props)
Inputs are the named, typed values a template component accepts from whoever places it — the component's configurable API. The author declares them as Props in the component's settings; each placement supplies its own values; and blocks inside the component read those values to render.
Declaring inputs (author side)
To open the component's settings, click the Template Settings (gear) icon next to the component's name at the top of the Hierarchy panel. Under Props, click Add props (or Add Field once the component has props), or Use code snippet to describe them as code. Each prop has:
Field | Description |
|---|---|
Key | Stable identifier. Changing the key after use can delete existing prop data — finalize keys before sharing the component. |
Label | Shown to placement consumers in the Inputs panel |
Type | String, Number, Integer, Boolean, Icon, Date, Date Time, Object, Array, Single Select Dropdown or Multi Select Dropdown |
Nest under | Optional. Places the prop inside an Object prop you already declared. |
Default value | Used when a placement leaves the input empty |
Builder value | Stand-in value shown on the canvas while editing the component — lets the author preview realistic content |
Help Text | Optional hint shown to placement consumers |
Setting inputs per instance (consumer side)
Every placement of a component that declares inputs gets an Inputs panel with one field per declared input. Each field is bindable like any other block property — one instance can feed a static value, another a data source result, another an expression from the surrounding page.
If the component declares no inputs, the panel is hidden entirely.
How blocks inside the component read inputs
Inside the component, any block, data source or function can read the values an instance passes in through the component's inputs:
{{ pageInputs['propKey'] }}
For example, a text block bound to {{ pageInputs['title'] }} shows whatever title the current instance supplied. Each instance sees only its own values.
Input update behavior
Note: Input values update live — they are not frozen at first render. When a bound data source resolves or the surrounding page's state changes, the new value flows into the running instance and re-renders it.
Slots
A slot on a template component is a named area the author leaves open so that each placement can fill it with its own blocks. The component owns the frame; the slot is the deliberate hole in that frame — it lets a component wrap content it doesn't own (a card that frames whatever body you drop in, a header with an open action area).
Declaring a slot (author side)
While editing the component, the author places a Slot block where consumer content should appear. Each slot carries:
Field | Description |
|---|---|
Key (slotName) | A stable, unique identifier generated automatically and not shown in the builder. Placements bind their content to this key. You can't rename it; deleting and re-adding the Slot block creates a new key, so content consumers placed in the old slot is lost. |
Label (slotLabel) | The human-readable name consumers see for this area. Safe to rename anytime. |
Description (slotDescription) | Optional hint shown to the person filling the slot. Safe to change anytime. |
Filling a slot (consumer side)
When a component with slots is placed, its instance shows a Slots panel with one entry per declared slot. Add blocks into each slot area — these blocks belong to the consuming page and keep that page's data bindings. A slot can also ship with default content from the author, which the consumer can keep or replace.
If the component contains no slots, the Slots panel is hidden.
Passing context into slot content
A slot can hand data to whatever gets placed inside it. The author defines a context schema — a set of named, typed fields the slot exposes — and supplies runtime values from the component's own data. Blocks a consumer drops into the slot can then bind to those values.
On the instance, a slot that exposes context surfaces it as slot state:
{{ instanceId.slots.slotKey.context }}
For example, blocks that fill a slot named footer on an instance with the ID card1 read the context the component published to them with {{ card1.slots.footer.context }}.
What renders when a slot is empty
At runtime an unfilled slot renders nothing — no placeholder, no empty frame, no reserved space. Design the surrounding layout so it still reads well with the slot absent.
Warning: The slot key is permanent. Deleting a Slot block and adding a new one creates a new key, and content consumers placed in the old slot is lost. The label and description are safe to rename anytime.
Component Overrides (Per-Instance Tweaks)
An override lets a placement change a specific property of a specific child piece inside the component — for that one instance only. Two things gate what's possible, and both are the author's decision:
The author designates which children are overridable. Only those children show up in an instance's Child components panel. A placement can never add its own overridable children.
Only certain block types and exposed properties. Overrides apply to a fixed set of simpler block types, and within those only to properties the author flagged as exposed.
Marking children as overridable (author side)
Open the template component in its builder.
In the Hierarchy panel, right-click the block and choose Mark overridable. Or open the template's settings and add the block under Component overrides.
To undo it, right-click the block and choose Unmark overridable, or remove its row under Component overrides.
You can mark Typography, Stack, Button, Icon, Text input, Template component, Icon button and Tag blocks. The root block can't be marked. The marking belongs to that specific block: if you delete it and add a new one, mark the new block again.
How overrides are stored
An override records only the properties the placement actually changed — a delta on top of the source. Every other property keeps following the source, so an author's later edit to an untouched property still reaches every instance. Clear an override to return the child to exactly what the source says.
What the Child components panel shows
When author-designated children exist, the Child components panel lists them on every instance automatically — ready to tweak, all still following the source until you change something. The fields start from your instance's delta, not pre-filled with the author's current values. An empty field means "not overridden" (the source value is in effect).
Note: Author-bound properties can't be overridden. If the author wired a child's property to a live expression, a placement can't override that property — it's locked to avoid silently breaking the component's logic.
Driving an instance from the host page
Beyond overrides, a placement can interact with an instance:
The instance publishes the component's declared output. The host page reads it with
{{ instanceId['output']['outputKey'] }}and reacts through the instance's On Output Change event.Each outbound event the component declares also appears in the instance's Events list, so you can add a handler for it on the host page.
When the component declares inbound events, the host calls into the instance with the Emit Inbound Event method — for example, a host button asking the instance to refresh.
Instance State Memory
By default, an instance that gets hidden and shown again starts fresh — its data source results, variables, and anything typed inside are reset. Turn on the instance's Remember state when hidden option to restore exactly where it left off instead.
Related Pages
Template Components Overview — the template component concept
Creating a Template Component — the author's workflow
Slots Overview — the general slot model