-
MotivationAs I was reviewing the I found this a bit counter-intuitive, especially given that the prop could be completely redundant in case the consumer of the component doesn't need a popover, and decides to render a Usage exampleN/A RequirementsIs there a reason for this API design choice? Should we consider moving popover-related props to the components rendering the popover ? WorkaroundNo response Possible implementationsNo response |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
In earlier versions, all those props were passed to the store. We changed this in v0.2.0. The plan was to move Regarding |
Beta Was this translation helpful? Give feedback.
-
|
Got it, thank you for the context!
Do you think this could be possible for |
Beta Was this translation helpful? Give feedback.
-
|
This might be possible, but I haven't tried it. |
Beta Was this translation helpful? Give feedback.
-
Just wanted to also flag that only the |
Beta Was this translation helpful? Give feedback.
In earlier versions, all those props were passed to the store. We changed this in v0.2.0.
The plan was to move
placementtoo, but it wasn't technically feasible since other components rely on this state.Regarding
open, you can control this state by passing props to components (see Ariakit Popover with open prop passed to component). However, this state ultimately belongs to the store, so internally, we'll sync this prop with the store state.