Add uniqueKey prop for identifying selected duplicates where superfluous fields exist in options

[laurenceks]

Is your feature request related to a problem? Please describe. Say I have a controlled typeahead:

<Typeahead multi={true} options={options} selected={typeaheadSelectedState} labelKey="name"/>

Where options is:

[
  {
    "_id": "63e273afd776024060b3750f",
    "name": "Banstead MRC",
    "organisationId": "626671867606e90645890483",
    "createdBy": "62793c06e0ae8296cb481550",
    "updatedBy": "62793c06e0ae8296cb481550",
    "createdAt": "2023-02-07T15:52:15.405Z",
    "updatedAt": "2023-02-07T15:52:15.405Z",
    "__v": 0
  },
  {
    "_id": "63e273b2d776024060b37514",
    "name": "Brighton MRC",
    "organisationId": "626671867606e90645890483",
    "createdBy": "62793c06e0ae8296cb481550",
    "updatedBy": "62793c06e0ae8296cb481550",
    "createdAt": "2023-02-07T15:52:18.966Z",
    "updatedAt": "2023-02-07T15:52:18.966Z",
    "__v": 0
  }
]

And typeaheadSelectedState is:

[
  {
    "_id": "63e273afd776024060b3750f",
    "name": "Banstead MRC",
  },
  {
    "_id": "63e273b2d776024060b37514",
    "name": "Brighton MRC",
  }
]

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.

[ericgio]

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.

[laurenceks]

Thanks @ericgio - let me know if I can be of any help!

[Nathan-Roberts123]

I would like to work on this feature, @ericgio can you assign me on this feature.