Confirming that in the example here, now with the boolean property you should actually see memory savings.

Even though boolean property also uses hidden layers, it still should net-net reduce the total number of variants and layers needed in a design system, thus improving the file’s memory usage.

For example for the button component set that’s built using just variants and variant properties: It includes two variants to represent the button’s two states. This component set has a total of seven layers (one component set layer, two variant layers, and four nested layers).

But if we use boolean properties instead, we need only one component and a boolean property applied to the icon to toggle its visibility. So this version has a total of three layers (one component layer and two nested layers).

With over 50% reduction in layers, there should also be more efficient file memory usage.

Also see our updated Help Center here.

Thanks for explaining it this way, I hadn’t thought about it like this before!

Hi @Sula_Yang , I could understand that if we use boolean property instead of more number of variants, the size of Design system main file will drastically reduce. But not in the file where we gonna use those instances right? Lets say I have converted 16 variants into 1. And if I use it anywhere which means all other hidden layers are still there in the file where I’m working.

and also it seems impossible to have an instance of another component to be linked to a boolean property to show/hide this instance, and not possible to have together a instance switch and boolean property linked to the same instance layer…

“Impossible to have an instance of another component to be linked to a boolean property”

This should be possible if you select the instance and create the boolean property from Layer in the design panel (see scrn shot)

“Not possible to have together a instance switch and boolean property linked to the same instance layer”

This should also be possible: Select the instance, setup the instance swap property from the instance icon in the design panel, and setup the boolean property from Layer in the design panel.

@Sula_Yang

Thank you for the official answer. But as he says, what about when an instance is used in another file, like a team library?

Thank you for bumping this up. Once you’ve reduced your variant set using component properties, that will also lead to file savings for when you use an instance. That is because when using instances Figma loads in the entire variant set so that variant swaps can work offline; but in the scenario where you’ve converted 16 variants into 1, we now only need to load 1 which should lead to memory savings. @Muthu_Nathan

Thank you very much. It was really easy to understand.

Now I can use component properties without worry

That’s awesome to hear and appreciate the great questions!

If you and others would like to learn more about component properties, please register for our upcoming office hours next Thursday 5/26

Even if you can’t make it, you can register so you get the recording afterwards!

I am experiencing issues with memory and this would help me a lot. One thing I haven’t been able to understand so hope someone here can make it more clear:

A large number of variants will slow down the file and use memory. Is it the same if you have used based components to create the variants? Does base components help save memory or do they equally make the file large when importing the instance from your library?

What’s crazy is that the answer here isn’t correct. @Sula_Yang I did more extensive analysis of this today. While it is true that the component itself will be smaller if you use properties vs variants, the variants are 2-3 times smaller when actually used. I created 480 frames on a page, each with 10 fields. I created 3 different types of components. 1) basic form field with label 2) complex field with mostly properties and few variants 3) many variants.

What I found was the following:

• Number 1 resulted in 3.4% memory consumption (the lowest)


• Number 2 resulted in 7.2% memory consumption (if the simplest field properties were set and 9.9% memory if a calendar icon and field tip was added from the properties) so even showing or hiding the layers with properties adds more to the memory usage.


• Number 3 resulted in 3.7% memory usage. For this one I did toggle on some of the different variants so it wasn’t using only the simplest one.

What this shows is the opposite of what was said here. Having properties being used and a bunch of hidden layers actually takes up more memory in your design file. Over the course of a larger application this becomes unbearable. I had trouble even doing small operations on this file with this many layers. I often work on applications with 1k+ pages and this would make it very painful to work.

What properties does do is make it easier to maintain the design system and component, so I guess you will have to judge for yourself which is best for your use.

This doesn’t seem to be correct. See my response above. Having hidden layers actually takes more memory which makes a file break after enough layers are included. Thoughts?

Thank you for flagging. Messaged directly to request file link/share to investigate!

Any update? I did what you requested but I haven’t seen a response yet. We are building out a design system that will be used by files with thousands of pages so this is an important topic for our company.

Are you saying we should be able to assign boolean props to something like an icon within a nested component? I mean, sure we can show/hide the entire component…but why would we do that?

Confirming shared with team and will circle back w any updates

Many thanks for sharing. Following up here after reviewing with our engineering team. After looking at the duplicated file we noticed a few things:

• The “Library Base Component” where you reference the higher memory consumption seems to be using instances that also tie back to a component set of 7 variants


• And in addition: These instances also have not only boolean properties, but also multiple instance swap properties and text properties


• Confirming that while boolean properties should have nominal impact to memory, instance swap properties and text properties can increase memory usage

We expect that if we wanted to support all the variation you have in “Library Base Component” with only variants, that would result in a sizable component set that would still likely use more memory than the the component property alternative.

Hope this helps! If you have additional questions feel free to file them here: https://help.figma.com/hc/en-us/requests/new?ticket_form_id=360001731233

Not sure I understand your description. I saw a huge difference in memory when using properties vs variants. Yes, the variant set would be huge if we had all of these options for the component, but my example file clearly shows that when a component is used, only the layers related to the variant chosen are included in the design file and not all of the other hidden layers and in the properties version, all of the other layers are there, increasing the memory usage and the amount of layers in the file.

Are you saying that isn’t the case, because I can create another example that is more simple that has just two variants and two properties and do a larger quantity test to show scale. I am sure the outcome would be the same. The more layers, hidden or not, the more memory is taken up.

So what it seems like is this:

• We can choose a component that has more variants, which will be harder to maintain in our system/library, but will have less of a memory footprint on the files we make


• We can choose to use properties in combination with variants to make a much less complex to maintain library component, but it will have an impact on the memory usage of the file we put it in

Are the options above accurate? @Sula_Yang

The main callout is that per the original topic, boolean props should have less impact on memory—however, instance swap and text properties (which you had multiples of in your example file) can in fact increase memory.

We understand keeping memory usage manageable is important, so support you pursue whichever option you believe is best for your design system.

For future support, feel free to file them: https://help.figma.com/hc/en-us/requests/new?ticket_form_id=360001731233

So your contention is that the instance swap and text properties are the things that are causing the memory to be much larger, and not the fact that there are tons of hidden layers for all of the other boolean props? Just want to make sure that is the basics of the answer. It just didn’t look like that was the case. it looked like it was the fact that there were a bunch of hidden layers on one and not on the other.

My team is having similar issues and I’m getting a bit worried. We’re heavily using booleans and memory usage has increased by quite a lot. So @Sula_Yang we’re saying if we limit instance swap and text properties we can reduce memory usage?

I did another test recently and it still remains that when I have a ton of variants it reduced the file size a ton. I put 6k fields on a page and the one with all variants was 5.6% memory and the one with only a few variants was 12% memory for the same number of fields and types of fields. This hasn’t been addressed, so for large designs, our system will have to have one of those sets of components where it just has a ton of variants for now. Hope this helps Alissa.

@Corey_O_Brien - I’m interested in your testing methodology. I’ve had the same question about how best to implement components with conditionally-displayed layers. My experience has been that when there is a large number of conditional layers, using boolean properties consumes more memory than using variants, but I haven’t done any quantitative testing.

In some of my use cases (e.g., tables), this could be addressed by the ability to include an arbitrary number of instances of another component. (See my post: Allow arbitrary/dynamic number of nested instances)

Oh man, this stinks. I guess we will have to recreate some components as it is a serious issue.

I created components for an input field. I then created a simple 5 field form with a few different types. I replicated this a bunch of times until I had around 6k fields on a page. I used 7 different sets of components with varying amounts of properties vs variants. The smallest memory usage page was the one with all variants. The worst was the one with the most properties. The only conclusion I can make from this is that the hidden layers from the properties takes up memory when rendering the page.

My situation was extreme in that I added 6k fields on a single page, but I was trying to make sure I could see the difference in the memory. Also, this was just the input field component. We will have much more complicated components, like tables or cards, that would have a lot more hidden layers.

I love the concept of the properties for making strong, yet easy to maintain components, but at my company, we do often have files with a thousand web pages and those thousand pages might have 15 components on each. We have some very slow Figma files a bunch, and do have to split up files to keep them running sometimes, so the more I can do at the component side of things the better it will be even if the component itself is hard to maintain.