Éviter un crash complet de l'application et remarques générales sur l'interface
publié le , mis à jourMerci beaucoup pour le travail sur cartes.app. J'aime beaucoup l'idée et je pense qu'une fois que l'application a un mode itinéraire et hors-ligne, elle pourra vraiment remplacer d'autres applications OSM. J'espère qu'un meilleur fond de carte pour le vélo sera développé (j'ai déjà vu quelques tickets à ce sujet), avec par exemple l'intégration des vélos en libre service comme dans la carte de Google.
Quelques remarques générales sur l'interface après avoir utilisé l'application à plusieurs reprises.
Je pense qu'il serait idéal de pas avoir un écran bleu/crash complet de l'interface pour ce type d'application. (comme on peut voir ici : https://codeberg.org/cartes/web/issues/920#issuecomment-8858631) Une notification dans un coin (ou au centre) de l'écran peut suffire ? Dans la plupart des cas, je pense que la carte peut s'afficher avec les informations manquantes, par exemple. (le serveur devrait toujours renvoyer la carte + une erreur si besoin)
J'ai aussi l'impression qu'il manque quelques indications de chargements. C'est particulièrement visible si la connexion internet n'est pas bonne.
Dès qu'un useEffect fait un appel API ou à une promise, je pense que c'est peut-être mieux d'utiliser tanstack-query (ou une autre lib similaire) ? (pas besoin de créer manuellement des états loading dans le code par exemple - https://tkdodo.eu/blog/why-you-want-react-query pour plus d'informations)
On peut aussi se retrouver avec des informations incohérentes dans le panneau latéral si on clique vite par exemple. Je sais pas si le logo de carte.app peut se transformer en une petite icône de chargement s'il se passe quelque chose ?
Un exemple ici où la requête a échoué, mais on a l'impression que c'est toujours en train de charger.
etienneJr
Merci pour ton retour d'expérience !
@hverlin wrote in https://codeberg.org/cartes/web/issues/1326#issue-2869023:
Je pense qu'il serait idéal de pas avoir un écran bleu/crash complet de l'interface pour ce type d'application.
Je suis d'accord que c'est un killer. Un utilisateur normal ne reviendra pas sur cartes.app après en avoir eu un. À un moment où certes l'app est encore en développement mais on cherche à étendre notre public il est temps de passer à qqch de plus discret. @laem c'est envisageable ?
laem
Pour le sujet des erreurs, c'est à double tranchant : plus l'erreur est discrète, moins elle sera remontée, et donc plus elle sera pérenne.
Dans tous les cas, je ne pense pas qu'on puisse encapsuler toute l'application dans un
try ... catch. C'est le langage de programmation qui limite. Et dans try... catch il y a catch : qu'est-ce qu'on fait quand il y a une erreur ?La chose la plus commune et la plus efficace à faire c'est de brancher un outil de suivi des erreurs. Pour 10 erreurs, il n'y en a qu'une seule qui est remontée par un utilisateur motivé. Avec Glitchtip ou assimilé, on les suit et on les corrige par priorité.
Le problème de ces outils, c'est qu'ils créent un tas de faux négatifs. En général en utilisant le leader Sentry, on se retrouve englouti par les erreurs et on voit vite l'historique disparaitre si on ne paie pas un abonnement mensuel. Mais ça mérite quand même d'être mis en place, notamment via des outils ouverts comme Glitchtip. Je l'avais fait, mais surveiller et entretenir le serveur prend du temps, donc il était tombé.
Bref, y a pas de solution simple à ça : faut bosser.
- réduire les erreurs
- les corriger rapidement quand il y en a
- les surveiller avec un outil
- plus long terme : mieux typer pour trouver les erreurs au moment où l'on code :)
Concernant le chargement : oui, ce serait bien qu'on améliore le chargement et qu'on fiabilise les requêtes (les relancer quand ça foire) et aussi qu'on améliore l'app sur de mauvaises connexions.
J'ai re-testé de mettre en ligne une instance d'un loggueur d'erreurs mais j'ai des problèmes sur l'envoi des mails. Je vais donc rebrancher Sentry en attendant.
OK Sentry fonctionne en dev, à tester en prod à la prochaine erreur
Ça marche en prod. Laissons-nous quelques heures et observons les erreurs les plus courantes pour agir.
Youpi. C'est consultable publiquement ?
@laem un des pb de l'écran bleu, c'est qu'il conseille de recharger la page alors que :
- dans >99% des cas ça ne résout pas le pb
- sur mobile en PWA, je n'arrive même pas à recharger la page, je suis obligé de fermer l'app et la rouvrir
Le message demande à poster l'erreur sur bluesky, en pratique ça n'est pas arrivé depuis plusieurs mois, n'est ce pas ? Si on ne peut pas utiliser sentry ou équivalent, pourrait-on ajouter un bouton qui enregistre l'erreur qq part ? ou déclenche un bot qui la poste qq part ?
en pratique ça n'est pas arrivé depuis plusieurs mois
Ah si parfois en message privé. Mais c'est rare, il y a tout autant de tickets créés ici.
Si on ne peut pas utiliser sentry ou équivalent, pourrait-on ajouter un bouton qui enregistre l'erreur qq part ? ou déclenche un bot qui la poste qq part ?
Non, c'est vraiment compliqué d'analyser les erreurs sur Sentry. On est noyé dans les erreurs. CF ce que je disais plus haut :
Le problème de ces outils, c'est qu'ils créent un tas de faux négatifs.
Voici une capture des dernières minutes. Il faut passer des heures à comprendre et corriger. Je te file l'accès à mon compte en privé, tu peux aller explorer 🔭
n4n5
@laem wrote in https://codeberg.org/cartes/web/issues/1326#issuecomment-8881992:
Dans tous les cas, je ne pense pas qu'on puisse encapsuler toute l'application dans un
try ... catch. C'est le langage de programmation qui limite. Et dans try... catch il y a catch : qu'est-ce qu'on fait quand il y a une erreur ?Je suis curieux, qu'entends-tu par le "langage de programmation qui limite" ?
Il y a les Error Boundaries https://react.dev/reference/react/useTransition#displaying-an-error-to-users-with-error-boundary
Oui c'est vrai qu'on n'utilise pas les ErrorBoundaries. Mais comment verrais-tu leur utilité ici ?
@laem wrote in https://codeberg.org/cartes/web/issues/1326#issuecomment-10142049:
Oui c'est vrai qu'on n'utilise pas les ErrorBoundaries. Mais comment verrais-tu leur utilité ici ?
Non cétait surtout une question par rapport a ta formulation de "limite de langage". Sinon pour ma part j'ai pas forcément eu de bug avec cartes.app jusqu'a mtn (sauf une fois mais non reproduit)