Comment by chrismorgan
9 hours ago
Half of that complexity springs from the requirement of being able to put any element as the radio button. If you’re willing to say “you can only use anything that can be expressed with CSS applied to the <input type=radio>, including psuedoelements” (which is plenty for thing like shadcn), it melts away.
The other half of it looks to come from an overloaded Label component which should probably have been split into two. There’s a reason that HTML has <fieldset> and <label> as different things. The implementation is also trivially incorrect: role=label isn’t a thing. Other parts of it are wrong or dubious too. In general, if the HTML way of expressing something isn’t permitted, the ARIA way of expressing the same thing is probably wrong too.
And so it goes, through the entire system. They assume you might want something ridiculously complex, and so they complicate and make worse the normal case.
Bingo!
For the "requirement of being able to put any element as the radio button.", Dan Abramov tells you that this is exactly the point of React, see his comment above:
> For what it’s worth, the point of React is that you can just fix that Radio component to be an input (if that makes sense) and it’ll just be an input. [0]
[0] https://news.ycombinator.com/item?id=46690762
You’re misunderstanding. This isn’t about React, it’s the Radix UI primitives library which is being overcomplicated by it allowing you to put any element as the visual part of the radio button.
As for “the point of React” being that you can just do such and such… there’s nothing special about React there, that’s what any of these component libraries achieve (React, Vue, Svelte, &c., even basic templating systems like Handlebars a lot of the time).
Am I?
I was just quoting the React creator.
1 reply →
Quite an ironic use of the word "fix" there.