Nesting and reuse
Widget.Using places an existing widget inside the current one, for reusable cards, layout fragments or composed pages.
Referencing a local widget
Namemust exactly match theWidget Namein the custom widget list.- Duplicate names count as ambiguous and are flagged in the editor; a missing widget shows an error placeholder.
Asis the alias inside the current widget and must be unique among siblings; when omitted it is derived from Name.
Referencing a remote widget
- The URL must be https:443 and goes through the launcher backend proxy.
- It is fetched and validated on first reference; afterwards it updates silently on a 6-hour TTL.
- The data domains of remote widgets must be confirmed in the parent widget’s editor.
Text shorthand
https:// is treated as a URL, anything else as a local widget name.
Passing initial input
Arguments is JSON and supports {Inputs.*} / {Data.*} interpolation; the child widget’s Inputs are initialized with these values.
Reading child state
The parent can read but not write:Dependencies and export
- Export only writes the current
.qwidget; local dependencies are not inlined. - The information panel lists the status of local dependencies: resolved / missing locally / duplicate name / remote.
- If a local dependency is missing at export time, you are prompted to distribute those widgets separately.
- To share a complete page, export the dependencies one by one, or reference everything by
Url.
Cycles and depth
- Maximum depth is 5 levels.
- Self references and A→B→A cycles are detected; once found, an error placeholder is shown and the rest of the parent widget still works.
- At most 20 nested instances per parent widget.
Lifecycle
- A child widget has its own
Inputs/Data/Results/Triggers/ script sandbox. - When a child unmounts, its timers, script sandbox and Blob URLs are cleaned up with it.
- Referencing the same local widget twice shares the data cache, but inputs and function results stay independent.