Have the capacity to "Link" component to start having some logic

Hey Sebastien,
you can create a larger component that has the different states of the group of radio buttons (e.g., First One Selected, Second One Selected, …) and you should still be able to get the hover state. That should get you some way there, I think.

Let me know if this helps!
— Niko

@nikolasklein How would this work when you need:
❖ A radio group with 3 items
❖ A radio group with 4 items
❖ A radio group with 5 items
❖ A radio group with 6 items
❖ A radio group with 7 items
❖ A radio group with 8 items
❖ A radio group with 9 items

❖ A vertical radio group with 3 items
❖ A vertical radio group with 4 items
❖ A vertical radio group with 5 items
❖ A vertical radio group with 6 items
❖ A vertical radio group with 7 items
❖ A vertical radio group with 8 items
❖ A vertical radio group with 9 items

without having to create hundreds of thousands of mostly identical variants + identical interactions on each variant (with the destination being the only difference)?

I love the new features, super excited to see them finally being released to the public, but the problem is simply this: when people started creating uncountable numbers of variants(main components), say that you roll out a new feature to solve the repetitive problem later on, how are people going to shrink their library down by then without making all already-instantiated instances wild pointers?

To be honest. your solution is working and this is a workaround of how things are done.
If you have 7 items in your radio group, you have to duplicate 7 times the same fame. Which make it really stupid.

I usually do not make a reference to it, but Axure manage that aspect really well for tabs or radios.

If figme want to be more proactive in the dynamic prototype, it will be one of the main challenge for your Product designers. Especially that you’re facing Product designer 😉

Oh yeah, it’s definitely just a workaround. We’re currently thinking through ways on how to make this a lot easier. It just didn’t make the cut for the first version of interactive components. 🙂

👍

I hear you on the concerns of creating unconnected instances after we release features that allow you to reduce the number of variants. It’s definitely on our minds!

Things like these are super tricky and we don’t want to hold back the existing value of our solutions until we have found the perfect one.

Specifically to this question; I would probably create:

❖ A radio group with 9 items
❖ A vertical radio group with 9 items

Since both of those would each have 9 variants it should be manageable and okay-ish. On the consumption side, I would just delete the ones that are not necessary. Since the ones that are left would still lead to the state where they are turned on and the others aren’t it should work.

And through externalizing the variants of a single radio button into its own component set, you can easily update the designs for the different radio button states.

This is actually the Perfect solution thus far, brilliant! You’re awesome @nikolasklein Love ya ❤️

Built it for you in case you are interested: Figma

(It’s a duplicate link so will duplicate directly into your drafts.)

Is this the perfect solution? Most definitely not! But believe me, I wanna get rid of noodle messes like this as much as possible!

Yup, relatively perfect solution(comparing to all current viable possibilities)! Hahaha 😜, still remembering Dylan deliberately pointed out “the noodle messes” that we’re going to solve on London Config ❤️ but I agree perfection can only be achieved little by little, day by day. It doesn’t just come by accident.

Axure handles this really well with “selection groups” Figma should look into emulating that.