Best practices

Wondering about another scenario? Have different opinions? Any nuances you would add? Let us know!

Many of these are general philosophies that aren’t specific to Plasmic, and are the same as when thinking about how to structure code or how to structure designs in other tools.

Variants vs. slots

Both variants and slots let you make different instances of a component look different.

When should you use one vs. the other?

First, to review some key differences:

• Variants let you change any element in a component, and you can change anything about them—styles, properties, and content. Slots let you swap in different content only, and this affects only what’s within the slot.
• Variants are defined as part of the component. They are available to pick from wherever you have instances of the component. They also ensure that all such variants of a component are consistent. Slots are customized at the instances of a component. You can put anything inside the slot; there’s no limited set of variations.

The main deciding factor: when there’s a fixed set of variations that should be controlled by the component author, then use variants. When the variations should be set by the component consumers (the users creating instances of the component), use slots.

Generally, prefer using slots to variants when you can. (For developers: this is equivalent to favoring composition.)

For example:

• For a Button, you might want primary buttons and secondary buttons. You’ll want all primary buttons to look consistent and all secondary buttons to look consistent. And you don’t want every instance of a Button to figure out what changes are needed to make it look like a primary button—you simply want to be able to insert a Button and select “primary.” For all these reasons, you should use variants for these.
• Any Button should be able to say whatever it wants for the text, so this text content should be exposed as a slot. You don’t want the users of a Button to have to go into editing the Button component and adding a variant of a Button for text that hasn’t been seen before (they may not even have edit access to the project that the Button was defined in, if say the design system is owned by a separate team).

Multiple components vs. multiple variants of a component

Say you are creating multiple things that look similar but have different content. For instance, you are making a multi-step form, and need to create each screen. Should you create multiple components, or multiple variants within a single component?

Typically, for minor content variations, such as toggling element styles and visibility here and there, use variants. For example, a Form component might have variants Expanded Details Section, Showing Error, etc.

For more substantial content differences, use different components. The multi-step form is a good example of this—each step of the multi-step form likely has completely different sets of fields.

But there may be surrounding chrome that is common to all steps of the form, such as Prev Step / Next Step buttons, the nav header, etc. These different components could use a single “template” component that exposes a slot for where the main content will go. (See the above section on Slots vs. Variants for more on this.)

Layout

Almost always use proper layout (stacks rather than free positioning) to ensure that your pages and components are fluid and scale properly on users’ screens, regardless of their device. You can start with free-form drawing, but should convert your designs to use structured layout before shipping.

Minimize the number of responsive breakpoints you introduce. This keeps your designs simple and reduce the number of variants that you will need to maintain and test.

Elements

Name an element if it might be interacted with from code—for instance, if clicking on it should do something, or if it should include dynamic data.

Have feedback on this page? Let us know on our forum.