Make it easier to use lower level primitives #1962
-
I love using Radix as the base for the design system I'm working on. Sometimes I want to do something more custom, like build a context menu with a filter input instead of relying on the typeahead search (similar to #787). I can't use the Radix Context Menu for this since it isn't meant to disable the typeahead and the focus-on-hover for its items. I also can't use the lower level Menu primitive since this is where the typeahead logic is defined. So although Radix has all the necessary logic defined to build a component like this (popper which opens at mouse position, menu element logic for radio groups, checkboxes, submenus, etc.), I can't use them because the logic is tied to the higher level Context Menu. It would be awesome if it would be easier to leverage the low level logic Radix already built without using the batteries-included components. E.g. to be able to compose the menu logic with the popper logic but leaving out the typeahead to create something that Radix doesn't provide as a high level component. Not sure whether this aligns with the direction of Radix but maybe it would be even easier to only supply independent design system logic blocks and let devs compose components like selects or dropdown menus themselves. I don't mind having a bit more boilerplate if I can customize components more. Anyway, thanks a lot for making it so much easier to build apps with great UX! ❤️ |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
Hey @dcastil, Thanks for the kind words! I understand where you are coming from. However, we think this is a minority and we are focused on offering complete components that work well. This helps us keep the public API surface to a minimum, hence why we specifically mention a lot of those packages are considered private as we may change and break things in them. Hopefully that makes sense. 👍 |
Beta Was this translation helpful? Give feedback.
-
I want this |
Beta Was this translation helpful? Give feedback.
Hey @dcastil,
Thanks for the kind words!
I understand where you are coming from. However, we think this is a minority and we are focused on offering complete components that work well. This helps us keep the public API surface to a minimum, hence why we specifically mention a lot of those packages are considered private as we may change and break things in them.
Hopefully that makes sense.
👍