Skip to content

CONCEPT Cited by 1 source

Parameter binding

A parameter binding is the edge in a parameter system that says "this specific layer property reads its value from this specific parameter." The layer property stops storing a literal value directly; it stores a reference to the parameter, and the runtime resolves the reference on demand.

Load-bearing invariant: at most one parameter per bound property

Figma's 2026 unification retrospective (Source: sources/2026-04-21-figma-parameter-architecture-unification) names this as the guiding principle:

The same set of properties should be bindable across parameter systems, and each layer property should be bound to at most one parameter.

Before unification, each parameter system (component properties, variables) stored bindings independently on the layer. That let a layer bind the same property to both a variable and a component property simultaneously — producing an unclear source of truth for that property's value and inconsistent rendering in the editor. The fix is structural: one binding store, one binding per (layer, property).

This is the same "design away invalid states" (concepts/design-away-invalid-states) discipline applied at the data-model level — a dual-bound property was an illegal state, and the fix makes it unrepresentable rather than detectable-and-fixable.

Why a shared binding store matters

If every parameter system defines its own binding-storage format, the document schema carries N parallel reference formats for N systems. Three consequences:

  1. Multi-bind becomes accidentally expressible. The schema has N places a property could be bound; nothing structurally prevents a property from being bound in more than one of them.
  2. Consistency checking becomes an O(N²) cross-check problem. To render a property you must check every binding store.
  3. Adding an Nth+1 parameter system adds an Nth+1 binding format. The schema ratchets in complexity every generation.

The unified binding store collapses this to: one format, one lookup, structurally impossible to dual-bind, one schema addition per type not per parameter system.

Binding granularity

Figma's runtime explicitly tracks parameter usage at the property level — parameter → {(layer, property) pairs that read from it}. This is the minimum granularity that lets invalidation gather exactly the affected properties when a parameter value changes, without over-invalidating entire layers. Figma's post explicitly calls out that unification let them tighten invalidation from layer-level to property-level — a perf win that the unified binding store made possible.

Binding across parameter-system boundaries

The invariant "at most one parameter per bound property" doesn't require the parameter to come from the same system the property belongs to. Figma's component property to variable binding feature binds a component property to a variable; the component property is still the parameter the layer property reads from, but that component property's own value comes from a variable. This is the resolution chain (concepts/transitive-parameter-resolution) — unified typespace is what makes it typecheck.

Seen in

Last updated · 200 distilled / 1,178 read