Variants allow components to present themselves differently on the screen. or Variants allow components to have a different representation on the screen. These changes may range from small details, like background colour, to radical changes such as a small button being replaced by a form.
Variants are based on the Figma variants‘ idea. As a matter of fact, when a component is generated from a Figma Component Set, its variables are automatically generated.
(The component with variants being created by Luna is due to be shown here)
Defining to what extent variables should be included in a single component and when it is best to create different components, it’s a difficult design decision to make. From a technical and performance standpoint, there is no substancial difference: both options have their pros and cons. From a deployment’s perspective, it will depend on each case, and the UX area will define it in tune with the Front End programmers’ definition.
Unlike switches, that change a single element and that element’s styles alone, variants may even change the entire HTML structure of a component, replacing it with a new one, without complexity limitations in the original or in the substitute.
The variant attribute
Variants are identified by integers: 0 is the default variant, and 1, 2, 3 etc., without skipping numbers, the versions that the component has.
To change a component’s variant, simply modify the variant attribute in the component tag, assigning the corresponding variant number. This can be done declaratively when the component is included in the HTML of a page, or programmatically with JavaScript.
Even when inspecting a component, if a value is assigned to the variant attribute, the component will change to the indicated variant. In the WCF, if a component has variants, a combo box is shown that allows to easily switch between variants.
If the variant attribute is assigned a value from a non-existing variant, the component will not undergo any modification.
Variants of variants
A component with variants may have subcomponents with variants in a chain as deep/long as needed. As one would expect, if the parent component’s variant hides the child component, no changes made to the child will have any effect.
Changes in the variant of any component in the chain affect only that component. They have no effect upward on the parent, grandparent, or other ancestors of the component. Downward, there is also no consequences for the variants, but depending on the design, some components may be hidden. If another change is made in the upper levels that causes this component to be shown again, it will retain the variant it had when it was hidden.
It is possible to modify the variants of components while they are hidden. An example of this behavior could be the following: there is a parent component in variant 1, and a child subcomponent in variant 2. The parent component is changed to variant 0, which hides the child subcomponent. While this subcomponent is hidden, it is changed to variant 1. Returning the parent component to variant 1 will display the subcomponent in variant 1, not the 2nd variant it was in when hidden.
Default variants
Components generated by Web Component Factory are designed so that in their initial deployment, each subcomponent is assigned the variant attribute according to how it was specified in the source from which the component was generated (Figma, HTML, or whichever is applicable).
This means that when the component is loaded for the first time on the page, and without any additional action, it will look exactly like the original.
(image missing – Luna is working on it)
From the initial deployment, variant modifications are independent for each component, and the default values cease to have an effect.
Variants and switches
Variants can certainly contain switches, and each one works according to its specifications, as expected.
To be noted: if a switch is present in more than one variant, changing its value will change it in all variants simultaneously.
Leave a Reply