Plots2: Les balises existantes ne s'affichent pas comme une correspondance exacte dans les suggestions automatiques de la barre de recherche

Merci d'avoir ouvert votre premier numéro ! Cet espace est protégé par notre code de conduite - et nous sommes là pour vous aider.
Veuillez suivre le modèle de problème pour nous aider à vous aider 👍🎉😄
Si vous avez des captures d'écran ou un gif à partager démontrant le problème, c'est vraiment utile ! ??
Rejoignez notre chaîne Gitter pour des discussions de brainstorming.

Salut @bhamster07 merci pour une observation et une idée très clairement documentées ! ??

Je vais essayer de démêler quelques détails ici pour vous aider. Mes questions:

1. quel est le tri actuel ?
2. où dans le code pourrions-nous insérer une correspondance exacte pour l'ajouter aux résultats ?
3. l'ajout d'une 2ème requête entraînerait-il un ralentissement ? (les saisies semi-automatiques sont très sensibles à la latence pour l'utilisateur - nous voulons qu'elles soient aussi rapides que possible)
4. devons-nous nous soucier de le filtrer des résultats restants une fois que nous l'avons ajouté en haut ? (ça a l'air facile alors pourquoi pas)
5. l'ajout de la correspondance exacte en haut aurait-il pour effet d'affecter d'autres fonctionnalités du site ? (c'est-à-dire utilisons-nous ce générateur de correspondance à d'autres fins où nous ne voulons pas cette modification ?)

OK, donc à 1) je vois ce point de terminaison où nous répondons à la saisie semi-automatique : https://publiclab.org/tag/suggested/mapping (uniquement accessible via JavaScript) :

https://github.com/publiclab/plots2/blob/158fadc6ed12b66bd0b17f65a134cef59b81cfee/app/controllers/tag_controller.rb#L394 -L401

Notez que ceci est différent de la saisie semi-automatique des balises dans la zone de recherche sur https://publiclab.org/tags , qui provient de ce segment de code .

En ce qui concerne 5) je tiens à dire avec prudence que le seul autre endroit où nous utilisons ce code est sur https://publiclab.org/search/tags

Je pense que cela signifie que nous pourrions insérer la correspondance exacte en haut de la liste dans ce code API plus profond :

https://github.com/publiclab/plots2/blob/158fadc6ed12b66bd0b17f65a134cef59b81cfee/app/services/search_service.rb#L79 -L91

J'aimerais également écrire un test fonctionnel pour cela afin de confirmer que la meilleure correspondance est la correspondance exacte. Je pense que cela serait basé sur ce test, et le suivre, en utilisant un mot entier comme "spectromètre":

https://github.com/publiclab/plots2/blob/3a05ae2d547c71d5a7d173741586397947fcbc00/test/functional/tag_controller_test.rb#L435 -L440

C'est génial car pour la correspondance partielle, nous verrions toujours cet ordre :

https://github.com/publiclab/plots2/blob/3a05ae2d547c71d5a7d173741586397947fcbc00/test/functional/tag_controller_test.rb#L439

Mais dans la correspondance exacte, nous verrions les éléments 1 et 2 changer de place. Cela devrait être un test formidable et spécifique.

Je souhaite proposer de l'ajouter au projet de marquage pour nos équipes combinées Outreachy et GSoC ! cc @17sushmita @Manasa2850 (plus bientôt sur la façon dont vos plans de projet peuvent se chevaucher ! )

Merci beaucoup d'avoir construit ce problème avec tous ces détails @jywarren ! ??