Replies: 1 comment 1 reply
-
Hey Sacha! We haven't looked much into the server components story. From what I understand about RSC though, I would think most of the Radix components wouldn't really be a good fit for RSC as most of them are highly interactive. Maybe that story would change once React adds first class support for mutations, but for now I feel like most of our components would need to be client components. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
This isn't really a targeted question, more of a general interrogation, so I hope this is the right place for this kind of discussion.
I love Radix but lately I've been running into two pretty big drawbacks that are making me reconsider my use of Radix, or of any similar React library for that matter:
One solution I'm currently considering is replacing Radix with a Vanilla JavaScript (i.e. non-React) library. On the plus side this should work for server components (at least I know it's a pattern supported by Astro), but I'm not sure if it'll be compatible with client components that are managed by React.
The other solution would be pure-CSS UI components, which are becoming more and more doable as CSS evolves. But the accessibility story can still be lacking…
Anyway I realize this is a bit outside the scope of Radix itself, but before I go down the road of migrating out of Radix (even if only partially) I wanted to know if the Radix team had any thoughts about addressing these issues.
Beta Was this translation helpful? Give feedback.
All reactions