-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge incoming style
prop on ComboboxOptions
, ListboxOptions
, MenuItems
, and PopoverPanel
components
#3250
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a note on something but I've got another question… do we want our props to override theirs or the other way around?
e77c2cc
to
c6dc327
Compare
That's a good question and it's a tough one. if you accidentally include Fwiw, currently we always override incoming props if we set certain props ourselves. Event handlers are always merged though. So based on this, I took the same approach. There are some exceptions where we prefer incoming props (e.g.: an |
yeah okay that seems reasonable. Given that undefined would also win (which I think would be undesirable) I think having ours override stuff is better. 👍 |
We were overriding the `style` prop entirely on the `<ComboboxOptions>`, `<ListboxOptions>`, `<MenuItems>`, and `<PopoverPanel>` for anchoring purposes, as well as provided some CSS variables. This now ensures that the incoming `style` prop gets merged in.
c6dc327
to
5811029
Compare
This PR makes sure that incoming
style
props are merged in with thestyle
prop that we provide.We were overriding the
style
prop entirely on the<ComboboxOptions>
,<ListboxOptions>
,<MenuItems>
, and<PopoverPanel>
for anchoring purposes, as well as provided some CSS variables.This now ensures that the incoming
style
prop gets merged in.Fixes: #3248