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.
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.
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
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
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.
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
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.
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.
Thank you @Matthew_Ortega ! It’s ridiculous that you should need plugins / hacks etc to do something that is web standard. Icons should inherit component / variant styles. Just like text.
Figma’s problem here is that they’re treating icons like just another component, when anyone who has ever been on the internet can see they’re not buttons or fields etc. They are a language, just like text.
Sometimes I swear the figma designers don’t think like designers at all.
Also, just fyi as a vet with 17 years design experience and who builds libraries every other month - these hacks don’t work. They work in specific cases for small libraries with zero variants or states.
Hello, i would like to share my two cents on this topic in hope it helps someone.
This is a file i created to explain the problem where you can have a component with an Icon and some text, and how when you manipulate the icon within another main component, it no longer switches variants correctly.
However, if you change the icon on an instance of the second main component, then it hovers correctly.
(I am super bad at explaining, you better grab the file and see it yourself.)
Thing is that i reported it to customer care, and it is a known bug that may (or may not) be fixed this month.
This is a known bug for ages. I recently came back to a previous design system that was working 100%, only to now have same issue again.
My solution (to the solutions mentioned in thread link below) was to Reset all changes to the icon components (layer) in my button masters, dropdowns, menus etc… I then had to set icon sizing inside them to where it was before. Luckily I use master componentents, but this is an embarrassment that Figma hasn’t fixed this, or worse patronizes professionals saying that it has.
Check out this thread if you haven’t tried the layer naming, unique color for icons set stuff first: