Lundalogik
New component - Radio button
New feature motivation
It is a common web element that is used in forms and similiar scenarios. It just makes sense to have it
Plus we want it in the dynamic checklist addon
New feature description
Something like this
Yeah, I absolutely agree.
This might be simple too, because we already have a radio-button template that is used by limel-list. It's not a full component, but I'd guess that converting it to one shouldn't be too difficult…
Totally agree! However, not something I feel we need to address the current cycle, rather focus on the issues we have. I Will put it into the cooldown board, since it feels like a good cooldown issue.
This will be a great addition. I've seen consultants using a checkbox and hacking it work like a radio button (so user can only select 1 choice). This could be very confusing for some users and can results in a really terrible user experience.
@adrianschmidt @jgroth
Me and @LucyChyzhova started making this as a new limel-component, but eventually came to this conclusion that it'll be nice to offer the radio button not as a single and stand-alone component, but wrapped into a list of radio buttons. Just like the Button Group component, which is in its core a radio button list too.
The reason is that:
- radio buttons can NEVER be 1, and they should be in a list with at least 2 radios.
- radio buttons should have a
nametag, which should be shared between them all (unlike checkboxes, or switches), - and just like the
id, thenameshould also be auto-generated for the consumer to do less work - it should b easy for consumers to send an array of labels and the list of radio buttons get generated for them (and they shouldn't care about putting one radio per row for instance, or adding
<br>s after each button)
So, with all that said, it feels we already have this feature 😂 and that's the limel-list with radio buttons!
I think what @joelricci or similar folks need is having limel-form and schema support the limel-list with radio buttons! so that they can incorporate them in forms.
What do you think?
And I think, in the "form" context, usually there is a question before the radio button or checkbox list. And that would be the label right?
Example:
What's your favorite fruit?
- [ ] Apple
- [ ] Samsung
- [ ] Huawei
So we should somehow make sure it's possible to have that, right @jgroth ?
Yeah the list is not compatible with the form right now, and it might not be an easy fix without making breaking changes since some props with the same behavior have a different name (items vs value) and some props are missing (label, helperText).
It should still be possible to use though, but you would have to create a wrapper that maps the properties correctly and renders any additional elements, e.g. label
Yeah, I'd say we create a wrapper, rather than make breaking changes to limel-list. At least as a step 1.
OK, since I don't know how this would be made, I'll leave this to you guys :)
what do you say @joelricci ?
I think it sounds very reasonable. And I want to stress that it's important (in Lime Admin for instance) that the layout allows the title (or what every property name will be chosen) to be a question just like in the figure above .
Also, a component like the one described here should make it possible for Lime Admin to natively represent "yesno" Limetype properties using the radio button component with just a "Yes" and a "No" option.
Another option for yes no could also be button groups, which we can think about. They take way less space. Another option that makes sense as well is the toggle Switch.