Working with Variants & States
Last updated
Last updated
Using the Design Kit and you’ll notice that there are several variants / states for some components. This can be things like the hover and disabled states of buttons or checked and unchecked states of checkboxes. In the Design Kit, all these states correspond to the way Material UI works. Using these components will automatically inherit the functionality of Material UI and all the states will work without needing to code much.
You can do something similar with variants in Figma when creating custom components. Each variant that you make will work as a state and Quest will also automatically create bindings for the differences in the states. Not everything will be as seamless as Material UI components, you’ll still have to code for hover states or use the Animate State feature. However, those states will all have the UI setup and your developer will only have to write the logic for when to show which state. This essentially allows you to get 80-90% finished with any custom component all from within your Figma design itself.
We’ll use this calendar list item as an example of how to set it up and how to preview it once exported to Quest.
You can make as many states / variants as you want, there is no limit to the number you can use. However, in every variant, you must have the same number of layers and make sure those layers are in the same order. So to make different states work properly, you will need to style the colors, fonts, type itself, layer style, size etc.
To code clean, we suggest and highly recommend you don’t add additional layers to one version of the variants. You can hide or show a layer in a variant so if you have something hidden in the first variant but show it in a later one, be sure the layer exists in all variants but only hide it where needed. Variant layers do not need to match exactly but when they match, adding bindings and features to matching layers will apply across all variants.
For code purposes, the top-left most variant in position will be the main variant and where all styles are derived from. Any edits to additional variants will make only the changes in code to that style and not rewrite the style as a whole.
To export to Quest, be sure to choose the top-level component that contains all variants, you can’t export individual variants.
Once imported, you can now use the drop-down in the top-bar to see how each of those states will look as a working React component.
From Quest, you can now set up State Triggers to control when each state/variant would apply. For example you could trigger showing the hover variant when “data.isHover” is true. You can set up similar conditions for all your states based on your props, data and fns.
Once you have set up the State Triggers, Quest will automatically figure out the differences between the layers in each state and automatically set up bindings to switch the styles. For example, if in hover state your BG color is red, then quest will automatically add a binding that will make the BG color red if the hover condition is met.