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)
In the component's settings, the author adds each prop with:
| Field | Description |
| Key | Stable identifier. Changing the key after use can delete existing prop data — finalize keys before sharing the component. |
| Type | text, number, boolean, date, dropdown, object, array, and more |
| Label and help text | Shown to placement consumers in the Inputs panel |
| 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 |
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
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. Placements bind their content to this key. Never rename after consumers fill the slot — their content bindings break. |
| 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:
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. Renaming a slot's key after consumers have already filled it breaks their slot content — their bindings point at the old key. 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 (text, buttons, icons, tags, inputs, nested components), and within those only to properties the author flagged as exposed.
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, which the host page binds to and reacts through the instance's On Output Change event.
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.
Frequently Asked Questions
Can I have a slot with default content that consumers can replace?
Yes. While authoring the component, drop a default block into the slot's editing area. That block is the default content for the slot. Consumers who fill the slot replace it with their own blocks; those who don't fill it see the default.
Why isn't my slot's context available inside the filled block?
Context is published only when both a context schema and matching values are set. If either side is empty, no context is published and blocks inside the slot resolve context bindings to undefined. Check that the slot's context schema has at least one field and that the context value is non-empty.
Can I override a property if the author bound it to a data expression?
No. If the author wired a child's property to a live expression, that property is locked and cannot be overridden per instance. The lock prevents a static per-instance value from silently shadowing the component's running logic.
What's the difference between an input and a slot?
An input (prop) passes a value into the component — a string, a number, a record, a boolean. A slot passes content — actual blocks the consumer places at an open area inside the component's layout. Use inputs for data, use slots when the component should frame external content.
Can a slot pass data to the blocks placed inside it?
Yes — use the slot's context schema and context value. The author defines the fields and supplies values from the component's own data. Blocks in the slot bind to those values via the slot's context state.
Related Pages
Template Components Overview — the template component concept
Creating a Template Component — the author's workflow
Slots Overview — the general slot model