Skip to main content
Question

How would you organize the variables to support this component?

RizePoint_Product

I’m trying to use the variables feature to reduce maintenance on some of our bigger library components. A good example is the button component, which currently has definitions for different colors/states/styles built in.

image

The problem is that this is a LOT of variants to maintain. If I could use variables to set size and color, life would be much easier. But I’m stuck on how to actually do that. My current best guess is something like:

  1. Create a collection that defines all the color variables for each component
  2. Create each color as a different “mode” within that collection
  3. Use the mode swap to control the color of the button in-context

But I’m not sure that’s the right answer, and without the ability to move variables between collections I’m hesitant to put a lot of setup work into something that may not achieve what I’m trying to do. Does anyone have any thoughts on how I could get this working with variables?

This topic has been closed for replies.

2 replies

Jairo
  • Jairo
  • 50 replies
  • June 28, 2023

I might be in the same boat as you. And thought to open a topic, but since yours is pretty similar, let’s talk.

For now, my base approach is:

  • Have one collection With the primitive values (For now raw hex colors)
  • Have one collection for button modes & states
  • Have one collection for link modes & states

But now comes my trouble, and I think it might interest you.

Which is your approach on how to define button state variables and modes?

I am thinking on two ways:

Case A

image

Having a separate subgroup for each state, two variables for each state to Background and label, and then as many modes as you please.
Once the variables are defined, you just apply both background and label color to each button state within the component set.
I think this structure is more similar with what we will see in css?

image

The only downside is that this table might not be pleasant to see.

Case B

image

In this case there are no subgroups, only variables for each button state, and two variables for the label: The regular and an alternative version.

I think this case is more complicated, as it requires you to select manually which variants of the button component will use regular label or alternate label.
But at the end of the day, the work in both methods are similar.

I don’t know what methodology to choose, or if there is another better method.

Hope it helps.

ReadyMade
  • ReadyMade
  • New Participant
  • 9 replies
  • July 4, 2023

In devmode you may notice that the variable name does not change. This means that you need to create a different root variation for each mod.

It also means that to apply the mod you will need to create an attribute for your component.

This was the task of the mods if we are talking about a light, dark version of the project. And that seems to make sense.

But if you do different variations to hover over a component, mods are an unfortunate solution. Because your name variable is unchanging.

So I would create state variations through groups and individual variables.

But in general, you can customise the variable name if you plan to export the json of your variables. It will just be different from what you see in dev mode.

Terms & ConditionsCookie settingsAccessibility statement

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings