Rechargement automatique des résultats

[fabienheureux]

J'ai fait un peu d'exploration sur la suppression du bouton rechercher dans cette zone, cf #956, on va avoir deux problèmes :

• Performances
• Non déterminisme des résultats
  Du coup même si on adresse le soucis de conservation des points déjà requêtés (comme contournement de l'absence de déterminisme des résultats), il faudra aussi tacler ce problème de performance.

On s'en reparle @kolok, je pense qu'il serait essentiel de s'attaquer à ce soucis de performances car ça nous permettrait de nous débarrasser d'un peu de dette technique qui me ralentit dans mes développements, mais ça impliquerait de geler les évolutions front pendant un sprint je pense.

Par problème de performance, j'entends qu'il faut environ 600ms pour afficher de nouveaux résultats, dès lors que la carte s'est "stabilisée".
En somme :

1. L'utilisateur déplace la carte
2. Le mouvement prend un certain temps pour s'arrêter
3. On envoie la requête au serveur qu'il nous faut de nouveaux points
4. Au bout de 600ms on a la réponse

On a donc plus d'une seconde entre le moment où l'utilisateur lâche la souris et le moment où on affiche de nouveaux points.

Pour donner un ordre de grandeur, on considère en général qu'un temps de réponse inférieur à 30ms donne une impression d'instantanéité à l'utilisateur. On ira probablement jamais jusque là mais il serait pas mal d'arriver sous la barre des 100ms.

Ce n'est pas mesuré par Fruggr mais en terme d'éco conception je pense que c'est notre plus gros bottleneck.
Sur des réseaux non fibrés (ADSL, 4g) ça doit être particulièrement flagrant.

Il n'y a rien d'insurmontable techniquement, et assez courant sur une première version d'un produit, mais ce serait bien d'adresser ce problème sans trop trop tarder car on risque de se prendre un mur le jour où on voudra effectivement supprimer le bouton rechercher dans cette zone ou alors aller plus loin dans l'affichage de la carte