reactive-programming

1 posts

figma

How We Rebuilt the Foundations of Component Instances | Figma Blog (opens in new tab)

Figma replaced its decade-old Instance Updater with a reactive foundation called Materializer. The change separates component resolution from layout and variable evaluation, while enabling granular updates instead of recalculating entire instance trees. Figma reports that common operations in large design systems are now up to 50% faster, and the architecture can support other dynamic features beyond components. ## Why the Original Architecture No Longer Scaled - Instance Updater was introduced around 2016 to resolve component properties, manage instance structure, and synchronize instances with their main components. - Over time, Figma added features such as: - Auto layout in 2019 - Variants in 2020 - Component properties in 2022 - Variables in 2023 - Slots, introduced as an open beta feature in 2025 - Modern instances can combine variants, variable bindings, auto layout, nested instances, variable modes, and extensive overrides. - A small edit can therefore propagate through deeply nested trees and trigger widespread recalculation. - Instance Updater accumulated specialized logic for layout, variables, and other integrations, making it increasingly fragile and slow. - In extreme cases, systems repeatedly invalidated one another, causing actions such as instance swaps or property changes to take seconds. ## The Goals of the Rewrite - Figma concluded that incremental optimization would not solve the underlying architectural problems. - The new design aims to separate responsibilities: - The instance system resolves which properties and children an instance should have. - Layout systems handle layout calculations. - Variable systems handle variable evaluation. - Updates should be granular, affecting only the portions of a tree that actually changed rather than rebuilding entire instances. - Figma also wanted reusable infrastructure for dependency tracking, reactive updates, and efficient invalidation across the editor. ## Materializer and Derived Subtrees - Figma built **Materializer**, a generic system that operates on the document tree. - Its purpose is to create and maintain **derived subtrees**—structures whose properties and hierarchy are computed from other sources of truth. - Component instances are one use case, but the same model can support features such as rich text nodes whose content is synchronized with an external CMS. - This broader abstraction allows teams to build dynamic features without embedding bespoke update logic into a single specialized runtime. The rewrite turns component instances from a monolithic synchronization problem into one application of a more general reactive system. By isolating responsibilities and invalidating only affected subtrees, Figma improves performance for complex design systems while creating a foundation for future dynamic features.