Radio button group: add new component

[TommyLindh2]

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

(updated 07-aug-2025 after discussions in the comments below)
True that Lime Elements lacks a radio button component. However, making an independent radio button component may be
The reason is that a single radio button is never useful in a UI. Looking at https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/radio
we can conclude that these are the requirements for a good radio button component:

• radio buttons can NEVER be 1, and they should be in a list with at least 2 radios.
• radio buttons should have a name tag, which should be shared between them all (unlike checkboxes, or switches),
  and just like the id, the name should also be auto-generated for the consumer to do less work
• it should be 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
  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!

However, this is undiscoverable for the consumers who come to our documentations page. They'd be looking for radio buttons, not lists.

Therefore, we need to make a wrapper component called limel-radio-button which accepts an array of items, and passes it to a limel-list with type="radio".

All accessibility, keyboard navigation, and so on, must be handled by limel-list instead.

Note

Note that we already have a RadioButtonTemplate which is only used to visually render a radio button for now. This template is inside the folder of limel-list. src/components/list/radio-button . We can move it out from there, when we make the new component.

Naming of the component

limel-radio-button-group seems like a much more descriptive and accurate name for this component, than limel-radio-button. It clearly communicates that this is a group of radio buttons, not a single radio button, which aligns perfectly with the earlier point that a single radio button is never useful in a UI.

This naming convention is also more consistent with common UI library patterns where grouped controls are explicitly named as such (like button-group, checkbox-group, etc.).

😄 Now the question is whether we need a limel-checkbox-group too or not 🤔 😅

[adrianschmidt]

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…

[blombergedvin]

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.

[Kiarokh]

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.

[Kiarokh]

@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:

1. radio buttons can NEVER be 1, and they should be in a list with at least 2 radios.
2. radio buttons should have a name tag, which should be shared between them all (unlike checkboxes, or switches),
3. and just like the id, the name should also be auto-generated for the consumer to do less work
4. 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?

[adrianschmidt]

Yeah, sounds like a very reasonable conclusion to me 👍

[Kiarokh]

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 ?

[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

[adrianschmidt]

Yeah, I'd say we create a wrapper, rather than make breaking changes to limel-list. At least as a step 1.

[Kiarokh]

OK, since I don't know how this would be made, I'll leave this to you guys :)

[joelricci]

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.

[Kiarokh]

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.