You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems that there's a particular behaviour that tells the DropdownToggle component (and maybe others) to use the children as "master button" if there's a single one, instead of creating a new one. I feel like it's a mistake:
It's not an intuitive behaviour - without looking at the source code, one might wonder what happens (I sure did)
The tag prop already allows us to customize the way the button is rendered, and is much more idomatic than adding props to already-rendered components.
It makes it quite harder to use icons inside a DropdownToggle (because the icon props are rewritten, so the classNames are lost). For example, the following doesn't work:
That is a bit weird. I am 👍 for removing that. I think at first I wanted a generic component for copying props onto whatever children are passed but it's really a dropdown button that behaves similar to other components (tag can be overriden). I don't think this pattern is followed anywhere else. Thanks for calling this out. I'll leave this open until this is resolved.
It seems that there's a particular behaviour that tells the DropdownToggle component (and maybe others) to use the children as "master button" if there's a single one, instead of creating a new one. I feel like it's a mistake:
It's not an intuitive behaviour - without looking at the source code, one might wonder what happens (I sure did)
The
tag
prop already allows us to customize the way the button is rendered, and is much more idomatic than adding props to already-rendered components.It makes it quite harder to use icons inside a DropdownToggle (because the icon props are rewritten, so the classNames are lost). For example, the following doesn't work:
One has to write the following:
In order to bypass the check.
Additional issues may arise (for example, without testing, I guess that such a pattern also breaks refs, and triggers more renders than required).
Would you consider removing this behaviour?
The text was updated successfully, but these errors were encountered: