feat(radio-group): migrate to signals

[ashley-hunter]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our
  guidelines: https://github.com/goetzrobin/spartan/blob/main/CONTRIBUTING.md#-commit-message-guidelines
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Documentation content changes
• Other... Please describe:

Which package are you modifying?

• accordion
• alert
• alert-dialog
• aspect-ratio
• avatar
• badge
• button
• calendar
• card
• checkbox
• collapsible
• combobox
• command
• context-menu
• data-table
• date-picker
• dialog
• dropdown-menu
• hover-card
• icon
• input
• label
• menubar
• navigation-menu
• pagination
• popover
• progress
• radio-group
• scroll-area
• select
• separator
• sheet
• skeleton
• slider
• sonner
• spinner
• switch
• table
• tabs
• textarea
• toast
• toggle
• tooltip
• typography

What is the current behavior?

Closes #442

What is the new behavior?

Does this PR introduce a breaking change?

• Yes
• No

Other information

I have migrated these directives to use signals, and have been able to significantly reduce the amount of code required. One change I did make - I can revert if we feel its important to retain - but essentially there was the assumption that a radio button may be used without a group. Personally I don't ever think I have seen an instance where a single radio button is used, as typically that would be what a checkbox is for. Accommodating the potential case for a standalone radio button results in potentially multiple sources of truth, for example, a radio button has a checked state and the group has a value representing which item should be checked. We can always make the group take preference, however this does add a lot of additional code and complexity for a case I don't believe is likely to occur. I'd be interested to hear if anyone has any strong feelings in retaining that functionality, and if so I can restore it.

[marcjulian]

This refactoring to signals looks really clean! I will close #344 for now. Perhaps with the new structure it will be easier to implement the changes to support card layouts (#246) and hlm components

e.g.

<hlm-radio-group>
  <hlm-radio value="16.1.4">
    <hlm-radio-indicator indicator />
    v16.1.4
  </hlm-radio>
</hlm-radio-group>

[goetzrobin]

Couple minor comments. I think this looks great!

[ashley-hunter]

Thanks, feedback addressed. If this is something we want to make consistent, we could add an eslint rule to enforce explicit method return types.

[goetzrobin]

Thanks, feedback addressed. If this is something we want to make consistent, we could add an eslint rule to enforce explicit method return types.

I am a fan of being as explicit as possible so I am down, but as always happy to hear everyone's thoughts!

[ashley-hunter]

I am a fan of being as explicit as possible so I am down, but as always happy to hear everyone's thoughts!

I tend to agree, particularly in a library, it can help prevent unexpected breaking changes due to method signatures changing, but yes, we can get consensus one way or the other and then make it consistent.