Feedback on refactor considerations for our popover component
Hi , I am refactoring our popover component for my project and would love your input on two different implementation approaches I 'm considering . I have recently found inspiration in Radix UI βs approach to building their highly flexible primitives with a compound composition strategy . I am considering adopting this structure in a toddle context with the context feature and slots . Single popover component : This approach involves a self -contained popover component that handles all the functionality internally , making it straightforward to use . Compound popover with context : This method uses a compound component structure , inspired by Radix UI , which provides more flexibility and composability but introduces more complexity . Key questions : - Which approach would you prefer in terms of scalability and maintainability ? - Do you have any experience with one of these methods ? I would appreciate any insights or feedback on my considerations . π I have a little experience with this . I think both approaches can introduce complexity and there is no "one way " . It 's one of those annoying "it depends " answers . π On the surface , it seems like both approaches would achieve the same thing ? If so , it 's about evaluating the benefit in terms of potential edge -cases , what flexibility would be gained , etc . @Max might have some opinions on primitives because I think this was an approach taken with Spark Pro (see https://pro.spark-agency.io/components-primitives-overview ) . In my case , the recent form builder I started working on uses a combination of components to achieve multiple things . For example , I have input , select and button components . The input is used to render form controls (one or more inputs ) for one specific input field rendered in the form e .g . one to control the label and one to control the placeholder . This is great because I can reuse one component , but the logic is more complicated and has resulted in a few refactors . The button is used in the select component to create a custom dropdown , however I can also use the button elsewhere e .g . for the form submit and cancel , for using as a input type CTA , etc . This is more flexible and easier to use but I had to do some refactoring for use with the select and it may have been easier just to let the component handle that instead .
