Comment by supermatt
6 hours ago
It doesn’t.
It gives a very naive approach that doesn’t support any complex styling.
For that you need to wrap the input and additional styling elements in a ref’ed label.
6 hours ago
It doesn’t.
It gives a very naive approach that doesn’t support any complex styling.
For that you need to wrap the input and additional styling elements in a ref’ed label.
Out of interest what's an example of styling that the radix/shadcn version enables that their approach doesn't? I was able to (AFAICT) replicate the radix docs example by just moving their styles around: https://codepen.io/mcintyre94/pen/pvbPVrP
In the example they are just using an empty <RadioGroup.Indicator/> for the pip as it is easy to target with a classname, but you can put any content in there instead for e.g. card-style radios (as used for complex selections, like a subscription tier).
By using radix, the underlying behaviour is compliant and identical for each of those implementations - you just change the content. Radix isn't looking at it like an html radio element, it is looking at it as a completely unstyled unique item selector.
The pseudo-element styling approach limits you to 3 layers - the container, and the 2 pseudo elements, none of which you can provide with meaningful content besides plain text. The best you can do is provide a basic styles and set background image. For anything else you need to use labels to either wrap the radio (in which case you can access state via sibling selectors) and/or ref them with "for" (in which case you cant access the state).
Wrapping it in a label is the idiomatic and correct way, and should be done even when not styling. Perhaps especially when not styling.
Putting an adjacent label is also possible, but scales poorly due to needing unique ids.
Can you give an example please? What kind of complexity are we talking about?
Any kind of nested markup: styled content, additional animation layers, etc.
But is that still less complex than what the author found?