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
Today, all inputs, selects, text areas, etc. that match child.type === Input (or Multiline, or Select, etc) will receive a bunch of props.
The problem is that React's type comparison is very loose. So, if your component is roughly the same type, it will receive the props. For instance, if you run the array of strings example without customizing the form's inputComponent to something other than input, it will pass unnecessary props to the tags input and mess up the behavior (thanks Chi on Discord for providing the example :D).
I don't have any solid idea of how to address this. Maybe we could check the child's props and see if there are any clues that this is a custom component (value, defaultValue, name, etc.), and if that's the case, we don't do our magic. But this doesn't feel much better than the current behavior to me.
In the meantime, anyone running into issues with custom components just needs to make sure their custom components are of a different type than their inputComponent, multilineComponent, etc.
Today, all inputs, selects, text areas, etc. that match
child.type === Input
(or Multiline, or Select, etc) will receive a bunch of props.The problem is that React's
type
comparison is very loose. So, if your component is roughly the same type, it will receive the props. For instance, if you run the array of strings example without customizing the form'sinputComponent
to something other thaninput
, it will pass unnecessary props to the tags input and mess up the behavior (thanks Chi on Discord for providing the example :D).I don't have any solid idea of how to address this. Maybe we could check the child's props and see if there are any clues that this is a custom component (value, defaultValue, name, etc.), and if that's the case, we don't do our magic. But this doesn't feel much better than the current behavior to me.
I'd appreciate suggestions :)
cc @diogob @gustavoguichard
The text was updated successfully, but these errors were encountered: