First of all, I really enjoy using Penpot, especially the token system. It’s been great for managing light/dark themes and keeping components consistent.
I have a component with multiple variants, some of them including an icon. Icons are SVGs, and I apply design tokens directly to their SVG elements (fill, stroke, etc.) so they adapt correctly to theme changes.
The problem I’m facing is when I want to swap the icon dynamically. When I replace one SVG icon with another, the token assignments are not preserved, and I need to reapply tokens manually for the new icon. This makes it hard to build flexible components where icons can be changed easily while still relying on tokens.
I’m not sure if I’m missing a recommended pattern here, so I wanted to ask: is there a best practice in Penpot for handling tokenized SVG icons inside components?
I’ve recorded a short video where I show the issue live and how it happens step by step:
Thanks a lot, and keep up the great work, Penpot has been a joy to use so far.
Hi @Deniz! Thank you for explaining this issue so clearly and including the video.
I have come across this exact same problem. I’m not really sure if there’s a better solution, but I have found a way to make it work.
The problem: The tokens get wiped when you switch variants because the paths that had the tokens applied to them aren’t in the new variant. This isn’t an issue that happens in SVG or CSS, because you can apply a rule to a parent element that affects its children.
I’ve made it work by using variants instead of overrides:
Create a variant for each icon with a property for handling the state, using the state as the value.
So this is the icon component in use, with a type of alert outline, a size of small, and a theme/state of warning:
This is the icon component itself, with the design token applied to its paths. It’s a quite a few variants for relatively few icons. Though you may not need a variant for every possible combination:
When creating the alert box variants (or button etc), choose the appropriate variants of the icon.
Then, when you switch themes, the tokens all work:
Ultimately, I suppose this is about codifying your design in variants instead of using overrides. But perhaps there’s a solution that could be designed as a feature that would prevent you from having to create so many variants!
Hi Laura, thanks a lot for the quick and clear response, really appreciate it!
That explanation helps a lot.
Just a small note for the devs: it would be great if there was a way to avoid having to create so many icon variants, especially to keep token behavior consistent. Anything that reduces variant overhead for designers would be really nice.
