Skip to content

SYSTEM Cited by 1 source

Figma Parameter Runtime

What it is

Figma Parameter Runtime is the unified substrate (2024–2026) that powers both of Figma's parameter systems — component properties (scoped, on-layer, launched 2022) and variables (global, library-level, launched 2023) — and that is designed to host a prospective third (Figma Sites CMS). It replaces two independent implementations (parallel type definitions + parallel binding-storage + parallel runtime pipelines) with a single shared architecture at both the data-model and runtime levels.

(Source: sources/2026-04-21-figma-parameter-architecture-unification)

Why

Pre-unification, component properties and variables were two separate systems with two visible failure modes:

  1. User-visible inconsistency. A layer property could be bound to both a variable and a component property simultaneously — no single source of truth → "inconsistent rendering in the editor." Users had no way to reason about which parameter won.
  2. Capability ceiling. A new parameter system (Figma Sites CMS) would inherit all the duplication and make it three-way, not two-way. The duplication was a platform-scaling blocker.

Plus two dev-facing failure modes:

  1. Doubled cost per new type. boolean support had to be implemented in both systems.
  2. Cross-system binding was structurally impossible. No number component property existed → couldn't bind a component property to a number variable.

Architecture

The runtime unifies along two dimensions:

Data-model unification

Two shared data-model pieces:

  1. One unified typespace. Single source of truth for parameter value types (boolean, string, number, color, …). Every parameter system references the canonical types — no more VariableType.BOOLEAN vs ComponentPropType.BOOLEAN. This is the patterns/unified-typespace-consolidation canonical instance.

  2. One shared binding store. Single format for "this layer property binds to this parameter," regardless of which parameter system the parameter belongs to. Invariant: at most one parameter per bound property (concepts/parameter-binding). The dual-bound inconsistency is unrepresentable by construction.

Deliberately not unified: the source-of-truth location for parameters. Component properties still live on component / instance layers; variables still live at the library level. That axis is orthogonal to the type + binding unification.

Runtime unification

The runtime handles reactive behavior via a four-stage pipeline, run once per parameter change, now shared across all parameter systems:

  1. Parameter usage tracking. Reverse index parameter → {(layer, property)} at property granularity. Built and maintained as bindings are created / destroyed.

  2. Invalidation. On a triggering event — parameter value changed, binding added/removed, layer's variable-mode switched — gather the affected (layer, property) pairs from the reverse index. Unified invalidation operates at property granularity across all parameter systems, rather than the prior layer-level granularity. This is called out as a concrete perf win: "substantially reduced the total time it takes to add, delete, and duplicate variable modes, as well as change variable values."

  3. Resolution. For each affected property, resolve its value. Direct binding → one lookup. Alias chain or cross-system chain → transitive walk through the parameter reference graph. With the unified typespace, the walk is typechecked end-to-end regardless of which parameter system any given hop belongs to.

  4. Updates. Re-render layers with resolved values. Unified update flow — single re-render pipeline for all parameter systems, replacing the prior two parallel flows.

What the unification unlocked

  • Component-property-to-variable binding (announced 2024-11-15 via @figma). The marquee feature — structurally impossible before the unified typespace, shipped as the post-unification proof point.
  • Performance wins on variable authoring — add, delete, and duplicate variable modes and variable-value changes all run faster, attributed to stricter property-granular invalidation.
  • Third parameter system for free. Figma Sites CMS (announced at Config) gets the runtime without re-paying the duplication cost. Figma Sites and Figma Buzz both plan to lean more heavily on parametrization going forward.

Interplay with adjacent Figma client systems

Figma's client now holds three bidirectional reactive graphs over the same document object model:

  • QueryGraph — indexes read+write dependencies between document nodes (FK edges + implicit layout/constraint edges). Powers per-session subscription + edit fan-out in Multiplayer.
  • Parameter Runtime — indexes parameter-to-bound-property edges. Powers reactive re-resolution when parameter values change.
  • Materializer (2026) — indexes source-of-truth → derived-subtree edges, recorded implicitly by automatic dependency tracking during materialization. Powers derived-subtree maintenance for component instances, rich text, and slots.

All three sit on top of the object-tree document model, all three use bidirectional in-memory indexes with push-based invalidation and property-granular granularity, but they index different edge types and serve different concerns. The 2026 runtime-orchestration unification (see patterns/runtime-orchestration-unidirectional-flow) is the substrate the three now interoperate through in a predictable update order.

Not disclosed

  • Absolute latency numbers for each runtime stage.
  • Memory cost of the unified tracking index at document scale.
  • Cycle-detection strategy in the resolution walk (variable aliases → variable aliases).
  • Migration path for existing documents with dual-bound properties (the very failure mode the new binding store makes unrepresentable).
  • Concrete algorithm details: graph walk order, scheduling across many simultaneously-affected properties, fan-out cutoffs.
  • The four-stage pipeline's relationship to QueryGraph's edit fan-out — does a parameter resolution re-run appear to peers as one property change per layer, or as a batched update?

Seen in

  • sources/2026-04-21-figma-parameter-architecture-unification — canonical description: motivation, data-model unification (typespace + binding store), four-stage runtime pipeline, property-granular invalidation perf win, component-property-to-variable binding unlocked, Figma Sites CMS as prospective third hosted system.
Last updated · 200 distilled / 1,178 read