Skip to main content

Widget references and scope

Widget.Using puts another QWidget inside the current widget. The child has its own data, inputs, function results and triggers; the parent gets read-only access.

Reference forms

Accessing state

The parent cannot write child state; for coordination, pass inputs through Arguments or keep the logic inside the child. When Widget.Outputs is declared, Data / Results are no longer exposed and the parent can only read Outputs.

Arguments

  • Supports {Inputs.*} / {Data.*} / {Results.*} interpolation.
  • Invalid JSON shows an error placeholder.
  • The child’s Inputs are initialized with these values; changes to Arguments update the corresponding inputs, and the child can still change its own inputs.

Dependency resolution

  • Local Name: looked up by name in the custom widget list. Missing shows “local widget not found”; duplicates show an ambiguity error.
  • Remote Url: fetched and validated through the backend proxy; fetched on first reference, then updated silently per the TTL.
  • Export: only the current widget is exported, dependencies are not inlined; missing local dependencies are reported before export.
  • Sharing: dependency widgets must be distributed separately, or referenced by Url instead.

Cycles and depth

  • Maximum nesting depth 5.
  • Self references and A→B→A cycles are detected; an error placeholder is shown once detected.
  • At most 20 Widget.Using instances per parent widget.
  • Duplicate aliases fail during parsing.

Lifecycle

  • A child runs its own Data, Triggers and Function independently.
  • Unmounting a child cleans up its timers, script sandbox and Blob URLs.
  • The same local widget referenced multiple times shares the data cache, but inputs/results stay independent.

Security

  • Remote nested widgets use the same silent update logic as top-level widgets.
  • Their data domains are listed for confirmation in the parent widget’s editor.
  • If a child contains scripts/commands, the parent editor shows a risk banner.