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
Both options are still selectable, despite having the same _id as the two items in selected. I think this is because options contains more fields than selected, thus they are not identical despite being the same 'option' in principle.
I don't think this qualifies as 'unexpected' behaviour, but is a little confusing when first encountered as the _id and labels are already selected. I cannot find any past issue/feature request describing this behaviour.
Describe the solution you'd like
Ideally <Typeahead> would have some kind of uniqueKey prop that would allow me to specify a key (in this case _id) that identifies the same option when the arrays passed to options and selected aren't literally identical but have duplicate _ids.
I think the values from options should take precedence when setting selected based on the keys. So in my example, on first render the selected array would be updated with the matching items from options replacing duplicates.
How is this solution useful to others?
This would remove the need to pre-process data to make sure the selected/options arrays have the same fields, allowing for faster development.
Describe alternatives you've considered
Currently I am mapping the array prior to passing to options to match sure objects have identical structures i.e. aren't removing all superfluous fields leaving just _id and name.
Additional context Options is loaded from MongoDB and stored in a global context, containing the extra fields (createdAt, createdBy, updatedAt etc.). This metadata is helpful in other areas of the app, so I do need to load it.
However, the metadata is not saved in the documents being used in this example. I'm currently having to duplicate and map the options array to match the structure that will be saved in the document (just the _id and _name field).
I appreciate it is important to ensure consistent data structure, however if a uniqueKey or similar prop was implemented it would avoid the need to pre-process data when passed a selected array with missing (but not needed) fields. I think this could be helpful and would really like to know what you think.
The text was updated successfully, but these errors were encountered:
Hey @laurenceks thanks for the detailed feature request! This seems like a pretty reasonable idea and something I'd actually thought about doing awhile back. I don't have a timeline for adding it, but will definitely consider it for an upcoming release.
Is your feature request related to a problem? Please describe.
Say I have a controlled typeahead:
Where
options
is:And
typeaheadSelectedState
is:Both options are still selectable, despite having the same
_id
as the two items inselected
. I think this is becauseoptions
contains more fields thanselected
, thus they are not identical despite being the same 'option' in principle.I don't think this qualifies as 'unexpected' behaviour, but is a little confusing when first encountered as the
_id
andlabels
are already selected. I cannot find any past issue/feature request describing this behaviour.Describe the solution you'd like
Ideally
<Typeahead>
would have some kind ofuniqueKey
prop that would allow me to specify a key (in this case_id
) that identifies the same option when the arrays passed tooptions
andselected
aren't literally identical but have duplicate_id
s.I think the values from
options
should take precedence when settingselected
based on the keys. So in my example, on first render theselected
array would be updated with the matching items fromoptions
replacing duplicates.How is this solution useful to others?
This would remove the need to pre-process data to make sure the selected/options arrays have the same fields, allowing for faster development.
Describe alternatives you've considered
Currently I am mapping the array prior to passing to
options
to match sure objects have identical structures i.e. aren't removing all superfluous fields leaving just_id
andname
.Additional context
Options
is loaded from MongoDB and stored in a global context, containing the extra fields (createdAt
,createdBy
,updatedAt
etc.). This metadata is helpful in other areas of the app, so I do need to load it.However, the metadata is not saved in the documents being used in this example. I'm currently having to duplicate and map the options array to match the structure that will be saved in the document (just the
_id
and_name
field).I appreciate it is important to ensure consistent data structure, however if a
uniqueKey
or similar prop was implemented it would avoid the need to pre-process data when passed aselected
array with missing (but not needed) fields. I think this could be helpful and would really like to know what you think.The text was updated successfully, but these errors were encountered: