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.
-
|
@benoitgrelard couldn't you separate out the pieces, some server some not? For example DialogTitle is static content and could be rendered as a RSC but the Root needs to be client side that accepts children? |
Beta Was this translation helpful? Give feedback.
-
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