I have a button component with the typical default, hover and active states for mouse over animation, nothing special. I want to click this button and:
Navigate to a new frame
Open an overlay on this frame.
If I map multiple On Click actions to a static element then this works. As soon as I try to map these actions onto a button component, only the first action of navigating to a new frame works. So I can’t get it to work on a hover animated button and I have no idea why this would be the case. I don’t have any conflicting actions with the danger icon on anything. Please help! Thanks.
Edit: To clarify, I even tested this with a component that had the 3 button states but didn’t have any prototyping links between the states in the component and it worked just fine. As soon as I added a link to a hover state variant the multiple On Click actions broke.
+100. I have been having this issue for years, and had hoped the newest Figma prototyping update would fix it. I have a published library with variant interactions for components such as buttons, which include standard interactions such as hover and press. However, when I use those buttons within prototypes in individual files, the variant interactions such as on hover and on press conflict with the prototype interactions I need, such as navigate to.
It appears that the built in variant interactions conflict with the local prototype interactions.
The only workaround I have found is to remove the variant interactions to get my local prototype interactions to work. However, this strips away interactivity from my prototype.
Same issue.
I am trying to use a switch to display/hide additional components on a form.
The switch component has the embedded action of going from normal->hover, and then on hover the click does normal-hover->active.
Adding the additional interaction to edit the variable does not work. Apparently it stops at only one interaction.
Had the same issue. For my particular case, I was able to work around it by putting my interactive component in a frame, and then apply the additional hover action (open overlay) to the frame.
I have the same issue. It would be great to be able to add a click action to a component instance, even if the original component had click interactions.
For context, I’m trying to create filtering where I can click on the list items, and the list item would both get checked (or unchecked) AND increment the counter variable by one AND change the Apply button status (controlled by another variable). Now I can have either or, as far as I understand.
I initially had the list item component (the checkbox + title) as part of the design file, and I got the interactions to work as intended. But when I extracted the component to our component library, I couldn’t get it working anymore.
Well same here.
From my point of view, all variant interactions are pretty much useless, if one cannot use them to prepare basic components and reuse them in more complex components.
Simply said: we need to be able to build basic buttons and derive more complex buttons from those simple buttons.
There is actually not even a workaround for this, e.g., by overlaying the button with a transparent rectangle and adding a click interaction to that rectangle, as interactions like hover will not reach the button, nor will click interactions set a variable.
Update:
You can actually have a hover interaction, but setting up a click- or mouse-down-up interaction leads to an additional instance interaction to be swallowed.
The way Figma likes to solve this is that on the target frame, you add an interaction “after delay” and then put your “open overlay” on that interaction. Then from your initial click, all you do is add a single interaction to the new frame.
The only downside to this is that no matter how someone navigates to that page, they will get your overlay.
I have solved it in the past by making TWO versions of the target page. One to keep in my regular flow and a second that I use only when coming from a particulat component interaction. A real pain if things get complex, but easy enough to maintain if you have a small project. Still tho.
I have had a few arguments with Figma support over this. They don’t like to see the user need here. I think it would be a pretty simple solve and they could even keep it the way it works with the interaction on the target frame, BUT it needs some sort of conditional logic. That is where Figma fails is that they do not think their tool needs this sort of thing.
