How to preserve icon color override and size?

[Yuan_Chang]

I have been trying to find a way to preserve the icon color override within my button component. As you can see here, I used the trick from Rogie (Perserve Icon Color Override) to apply union to the icon, and everything seems work.

However, now when I swap an icon, the union makes it hard to control the icon size (even though all icons have a frame 24x24, the content inside are vary). It then affects the auto layout and size of the component. Therefore, I tried to add another frame to contain the union layer and set fixed size, but it still didn’t work at all.

With the old approach, which I have to change the color every time, it allows me to constrain the icon size within the button to be 16x16. I am wondering is there a better way to preserve both color override and icon size?

[tank666]

What if only the icon was wrapped in a union, and not the entire component?

You can see this file:

Figma - Material Design Button — Interactive Components (Auto Layout +...

[Peter_Bentley]

Thanks @tank666 for your file.

I have two large libraries I’m managing for my team (one for icons, one for UI components) and was struggling to make icon colors work for both dark and light theme for several hours this afternoon. Here’s what worked for me:

1. Do the Union trick from Rogie’s file: for me, I duplicate my expanded icon in place (cmd+d), then union the two dupes, delete one of them, rename the union item to something like “color_fix”, the icon vector itself to “Union”, and the frame containing it all to the name I want for the icon (e.g. “keyboard”). Convert this to a component if it isn’t one already.
2. Make sure all the items are set to Scale for height and width
3. Make sure no color styles are applied anywhere in the stack; just some generic black color or whatever
4. Publish the icon library
5. Accept the icon library updates in the UI components library
6. In the UI components library have a component with two icons in it, one for light theme and one for dark
7. Use those icon components throughout the UI components library file.
8. Apply the colors you want to the light icon and dark icon (I applied the color on the level of the item labeled “color_fix”)

Doing all of that enabled me to actually see the icons scale correctly to several different sizes within different components and also reflect the correct color depending on which theme the UI component pertained to.

[Yuan_Chang]

Thanks for the advices above. I actually remade all of my buttons in order to fix the icon size. One thing I learned is that Rogie’s trick works, but it’s very important to set a frame for the icon first rather than having the union then create a frame to wrap it.

[KubaA]

I must say that this sounds like a workaround to a bug. Wondering if this will be fixed soon as it makes using variants and interactive components nearly pointless when there is an icon-placeholder

Update: problem fixed with naming each shape for each icon with the same name. Color override works properly now. There is no bug.

[Timj]

Variant icon color not being static is definitely a bug. I’m totally against hacks like this as it complicates the components, I remember the Sketch icon masks I had to maintain.

[Peter_Bentley]

I don’t like hacks either, but I do like that my icons are now getting the right color for each theme, even when I override the icon selection for, say, a button. My update to this thread is that I now am no longer using an icon component with a dark and light version; I’m just letting the parent component (say, the button) do the color overriding and it seems to be working. I probably don’t need the icon container anymore, but I also don’t want to touch it because it’s working.

[ash]

thanks KubaA, this is definitely the best way to address preserving icon colors!

[Jakedeg]

Seems like it will also work to use a modified version of Rogie’s trick where you put a union within each icon component rather than within the button component that contains the icon. I think I prefer that way, since they’re already framed, and I don’t have more nested components to click around in my button. I almost never have to dig deep into the icon component itself, so the union there is mostly out of sight, out of mind.

[Tobias_R]

This was 100% the answer. My team uses FontAwesome as glyphs… So we originally had every layer named the FontAwesome html (far fa-icon-name) so devs would know which icon to use exactly. Just had to copy/paste that into the Description instead and then rename all the layers to the same name: “Icon”. Works perfectly now!! Thanks so much

[Menno_Weerepas]

It’s all in the name. I just found out . over 500 icons in our DS each one of them in a symbol 16 x 16 with a unique name off course. But the element inside could have different names like “vector”, “union”, “primary”, or whatever. Once I noticed that elements with the same name didn’t switch color I’ve named every element “vector” and it works. Now I have to change this hack back again

[Jesse_Payne1]

Have just implemented this trick so I can put up icons with hover states with the new interactive components. Kinda annoying because I’m going to have to slowly replace all my icon buttons across almost 100 files.

…So wild that this is so similar to something we used to do in Sketch to get colour overrides to persist in 2016/17.

[Andrew16]

I am still having problems with this. Keeping the icon layer name trick as @KubaA advised all the same within the .base / parent master components still doesn’t retain overrides…really frustrating…

Double triple handling entire design systems here we go.

[AlicePackard]

I’m having a hard time understanding what Rogie’s set up offers that is different or better than using overrides and swapping with a simple flattened vector:

This is not a union, it’s just a vector in a main component frame. The main component is named after the shape, and the vector nested within is named “Icon”, and this naming structure is what allows us to override an icon’s color (at the “Icon” layer level), swap the component with another, and that overridden color will persist after the swap is made.

Here’s an example of this happening when the icon is nested inside a component like a button. I used Rogie’s file in this example:

The pink color override persisted after I swapped because the vector layer inside the icon component shared the same name and structure.
The size of the icon persisted after I swapped because it’s following the size I set in my button component. All the original icons in Rogie’s file are 39x39px, and you can see I shrunk this down to 21x21px for my button component.

If I’m misunderstanding the use case for Rogie’s method I’d appreciate someone letting me know I was surprised to see this thread for a lot of the reasons folks have already mentioned: this method reminds me of what had to be done in Sketch, and I very much don’t want to return to that world

If folks would find it helpful, here’s a view-access link to the Figma file I used to create those screenshots and GIFs to get a closer look at the layers and whatnot.

[Roman_Victorovich]

doesn’t work

[YuanChang]

It looks like the new update allows people to use same layer name + structure to achieve it

[Alexandre_Istrasoft]

for any components, to preserve override properties when switching, the layer STRUCTURE and NAMES of all layers inside all switchable components need to be IDENTICAL

[Sam18]

@tank666

Figma - Material Design Button — Interactive Components (Auto Layout +…

Also unable to make this work. All icons have the same name, unionized the icons in the icon library and still not working. When I change state or theme (colour) using properties, the icons remain the origin colour.

[tank666]

Could you share a link to an example file?

[Matthew_Ortega]

To be honest, it seems like a lot of people in the Figma community get excited about hacky workarounds to things that should be straightforward. As a design system maintainer, I get a lot of complaints over things like this, and there is no reasonable way to solve them. Most designers won’t learn the hacks.