Components and instances: an in-depth look

Components

Components can be understood as a very special type of frame. Their own properties and the properties of all layers inside, including the relative positions, layouts, or constraint relationships between layers, are encapsulated into a "standard paradigm." Components serve as functional units that are meant to be repeated or reused, such as a "button."

A component can exist as an independent entity.

However, more often, due to the need to present different appearances or even functionalities in different scenarios, components often appear as a collection of sets. Additionally, by adding component properties, the functionality of a component can be further extended.

Learn more about Component Properties

Instances

Instances, as "children" of components, inherit almost all property values of the components. Modifications to the components can be applied to all instances with one click.

Properties that will be inherited include:

Descriptions of the component's structure: containing layers, layer hierarchies, relative positions, layouts, and constraint relationships between layers.
Descriptions of the component's appearance: size, opacity, fill color, text content, corner radius, stroke thickness, shadows, and other special effects.
Descriptions of the component's functionality: states and additional defined properties available for switching, defining interactive logic for transitioning between different component states, such as transitioning from the default state to the hover state when a button is hovered.

Properties that will not be inherited include:

Descriptions of the component's position and posture on the canvas: x/y coordinates, rotation, mirroring, etc.

Note: Rotations, mirroring, etc., applied to layers within a component will be inherited by instances. For example, rotating the overall component and rotating the layers inside the component might seem to result in the same change, but the behavior of instances is different.

Components vs Instances

	Component	Instance
Purpose	To encapsulate reusable functional units, a crucial component of design systems.	To build design drafts, ensuring synchronization with components while allowing some degree of independence.
Creation Methods	Select the layer or layer structure to be converted into a component, then click the Create Component button in the toolbar. If a component corresponding to an instance is deleted, the component can be restored through this instance. Copy an unpublished component to another file.	Copy an unpublished component and paste it in the same file. Copy a published component and paste it in any file. Drag it out from the components panel. Copy and paste an instance.
Features	Can freely add or remove layers and adjust layer structures. Can include instances but not other components. Can be published for others to use. Can freely add additional component properties. Can add smart layout. Can include descriptions and documentation. Can include interactive actions showing component states.	Inherits and overrides. Cannot freely add or adjust layer structures. When a layer is deleted within an instance, the layer is hidden but not actually deleted. Cannot be directly published for others to use. If you modify an instance to be different from the component and want to promote it for wider use, you can encase the instance in a "shell" component before publishing. Can switch in place to instances of other components. Can only use additional properties preset by the component, unable to add, delete, or modify component properties. If the component has smart layout, the instance cannot remove it but can override its property values. If the component includes descriptions and documentation, these can be viewed but not modified when using the instance. If the component includes interactive actions showing component states, the instance can trigger them during presentation but cannot modify them. Can be used to recover components if they become invisible.
Additional Details	Since they are a "special type of frames," the layer name is also displayed in the upper left corner of the component on the canvas. Identified as a solid diamond shape in the layer tree. When a component is selected, the create component functionality in the toolbar changes to Create Variants.	Does not display layer names on the canvas. Identified as an outlined diamond shape in the layer tree. When an instance is selected, you can continue to use the Create Component Tool.

Overrides

Sometimes, we need an instance to have its individual attributes to a certain extent and want these attributes to be preserved without being influenced by the component. These intentional changes, which release the instance from the control of the component, are referred to as overrides.

After dragging out an instance, you can make changes to any properties of any layer within the instance:

Changes made to an instance won't affect other instances or the component.
These changes override the values inherited from the component for the corresponding properties, freeing these attributes from the control of the component until the respective modifications are reset.

Note: Switching instance component properties may seem to cause a "change" in the instance. However, this change is not an override because component properties are preset abilities of the component, and adjusting these properties doesn't alter the component itself.

Use cases for overrides

Modifying individual visual styles of a component in cases where the design system has not defined them. For example: the shadow usage specification of a certain business design system has not been defined, and the designer modifies and overrides the shadow style of the component according to business needs.
Iterative exploration during design system evolution.
Quickly outputting a last-minute design task using standardized components. For example: if a company initiates a new verification project requiring a prompt launch, mature business components are employed to construct the page. However, due to significant differences in overall positioning and style, adjustments to the component style are necessary.
Modifying text on the interface based on specific scenarios. We strongly recommend utilizing the text content function in the component attributes to define text layers that may require flexible adjustments as “dynamic content.”

Learn more about Component Properties

Preserve color and size overrides when swapping instances

When using components nested with other instances, we often switch between instances and want to maintain modifications to size and color.

Consider the following example with buttons containing icons:

The default icon size is 24px; if you want the icon size to remain 32px after switching, ensure that all shape layers within the icon components have constraints set to scale with parent.

The default color for all icons is gray; if you want the icon color to remain blue after switching, ensure that all shape layers within the icon components have the same layer name. In the example below, all shape layers for icons are named "shape."

Possible misuse of overrides

Widespread use of non-standard overrides for component styles during mature business design iterations.
Repeatedly modifying and overriding component styles using standardized styles, leading to a loss of the benefits of unified component updates. For example, switching from style A to style B and then back to A, it may appear that the style is still A. However, overrides have been applied, preventing subsequent use of unified component updates.
Careful and restrained use of overrides can significantly enhance design flexibility while maintaining a consistent user experience. However, prolonged and excessive use of overrides may lead to a gradual loss of effectiveness in the design system. In extreme cases, it could result in system breakdown, impacting iteration efficiency and user experience.
When switching team libraries for theme changes in design drafts, widespread overrides may occur. Currently, there's no one-click method to reset all instance styles to the inherited state, so it's not recommended for extensive design drafts.

Learn more about Swap Team Libraries

Note: If team members consistently and extensively engage in override behaviors, it may indicate that the component library is no longer meeting the needs of business iteration. Regularly check and update the team library.

Reset instances

You can reset overrides for an instance.

Select the instance you want to reset and find "Reset all cverrides" in the right-side properties panel. You can also choose to reset only the size or layer names.

Detach instances

Sometimes, for quick design completion without considering persistent maintenance or to avoid the influence of component changes, you may want to detach an instance from its component. This allows complete freedom from component control and facilitates conversion into a new component after modifications.

Select an Instance, select detach Instance in the right-side properties panel, or use the keyboard shortcut:

Mac: Option + Command + B
Windows: Alt + Ctrl + B

Note: If detaching instances occurs consistently and extensively, it may indicate that the component library is no longer meeting the needs of business iteration. Regularly check and update the library.

👍🏻 Helpful or 👎🏻 Not Helpful

👉🏻 Was this article helpful to you? We look forward to your feedback.
👍🏻 Helpful
👎🏻 Not Helpful