search

meilisearch / meilisearch-js-plugins

The search client to use Meilisearch with InstantSearch.
https://www.meilisearch.com
MIT License
473 stars 59 forks source link

`instant-meilisearch` geosearch overwrites `objectID` #1308

Closed queer closed 1 month ago

queer commented 3 months ago

Description I have an index I am using geosearch on, using instant-meilisearch + react-instantsearch. Something I noticed is that when I try to use hit.objectID for anything, it's never the actual value that's stored in my Meilisearch index or the value returned in the network requests, but instead always a seemingly-random number. Today I traced it down to adaptGeoResponse explicitly overwriting the objectID field:

https://github.com/meilisearch/meilisearch-js-plugins/blob/bc9b833f743da137817e2270dc8284d9e80ea449/packages/instant-meilisearch/src/adapter/search-response-adapter/geo-reponse-adapter.ts#L7-L16

It seems that this behaviour has been a part of the geo-response-adapter since the beginning: https://github.com/meilisearch/meilisearch-js-plugins/commit/ac697077a4cfe1a53ea222d7f1f3c3fd618cecff#diff-b1f517006a5289a6c011e39668cc44e828b73d2056a2ff00cf04e01bc4bfcafcR13

Expected behavior instant-meilisearch doesn't change the data I get back from Meilisearch.

Current behavior instant-meilisearch changes my objectIDs to unwanted, useless values. I have to use a workaround of getting the value from hit._highlightResult.objectID.value.

Screenshots or Logs image image

curquiza commented 3 months ago

Hello @queer Thanks for the report

Indeed, that's an issue. However, with @brunoocasali we don't know what would be the best way to fix this. Do you?

Pinging @flevi29 if you are around too 😇

queer commented 3 months ago

Digging a bit further, I found the justification for why this behaviour exists: https://github.com/meilisearch/meilisearch-js-plugins/pull/543#discussion_r728135417

InstantSearch requires an unique identifier for every marker on the Google Maps. Without that ID the geo point is ignored. Since algolia always provide the same id field :objectID but we don't as they might change from one dataset to the other. So we created a randomly generated id

It makes perfect sense why this would happen, I just wouldn't expect it to overwrite objectID if there already is an objectID present; presumably? datasets that contain an objectID field wouldn't have duplicates.