Skip to content

feat(ux): enhance notifications on a modified transaction - #194

Open
lmandrelli wants to merge 1 commit into
mainfrom
feat/transactions-notifications
Open

lmandrelli wants to merge 1 commit into
mainfrom
feat/transactions-notifications

Conversation

@lmandrelli

@lmandrelli lmandrelli commented Sep 19, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Remplace les messages superposés à la modale du comptoir par des notifications en haut à droite de l’écran pendant 2,5 secondes. Après validation, annulation ou remise en attente, la modale concernée se ferme immédiatement : on peut ouvrir la transaction suivante sans attendre la disparition du message « Transaction validée / annulée », accompagnée du surnom et du nom.

Les délais servent uniquement à retirer les notifications. Ils ne ferment jamais une modale et ne modifient pas la recherche. Chaque ouverture possède sa propre instance et ses propres callbacks : une réponse tardive concernant A peut afficher sa confirmation pendant qu’on consulte B, sans fermer B ni altérer son brouillon. Cette protection s’applique aussi lorsqu’on rouvre la même transaction.

  • Cartes de notification en haut à droite, fond neutre, icône de statut, titre de l’action et affichage « surnom (nom) » comme dans la liste. Le nom seul est utilisé sans surnom, sans doublon si les deux sont identiques.
  • Notifications non bloquantes, annoncées par une région aria-live, avec un délai indépendant de 2,5 secondes et une barre de progression. Adaptation au thème sombre et aux préférences de réduction des animations.
  • En cas d’échec HTTP ou réseau, la modale reste ouverte avec les modifications saisies ; une nouvelle tentative est possible immédiatement.
  • Les boutons d’action et de modification sont désactivés pendant une requête pour éviter les doubles envois.
  • Après une écriture partiellement réussie, les états déjà confirmés sont mémorisés pour éviter de les soumettre à nouveau lors d’un réessai : le backend refuse un changement vers l’état déjà enregistré.
  • Les lignes dont l’annulation est déjà confirmée ne sont plus renvoyées lors des sauvegardes ou réessais : cela préserve leur coût nul, le total et le remboursement après une écriture partielle.
  • « Enregistrer » conserve la modale ouverte et recharge la transaction. Aucun changement du backend ou du contrat API.

Validation

  • npm run build et git diff --check : réussis.
  • npm run check : les mêmes 8 erreurs et 51 avertissements préexistants, sans nouvelle erreur.
  • 49 scénarios navigateur réussis avec les vrais composants de liste, modale et notification, une horloge virtuelle et une API simulée : rush vers une autre transaction, fermeture/réouverture dans le même cycle, réponses tardives, réouverture de la même transaction, doubles clics, erreurs et réessais après écriture partielle, conservation du brouillon, délais indépendants de 2,5 secondes, placement en haut à droite, variantes de nom/surnom et nettoyage après navigation. Le mock reproduit le refus backend d’un état déjà enregistré. Scripts temporaires hors dépôt.
  • 14 scénarios navigateur avec les vrais composants, le client Axios du dépôt, le backend Go recompilé et MongoDB : 174 assertions, 109 appels tracés, aucune erreur non gérée. Succès, erreurs réelles 400/500, 503 et coupures réseau injectés, réponses retardées, navigation vers B, doubles clics, sauvegarde, remise en attente et réessais après écritures partielles. Contrôle de l’identité DOM et des montants, remboursements et stocks en base.
  • Charge sur 100 000 transactions historiques fictives et trois transactions QA : 181 164 lectures en 120 secondes à 24 requêtes simultanées, sans erreur ; p95 27,01 ms et p99 33,32 ms. Prolongation de 60 secondes à 8 requêtes simultanées : 69 343 lectures sans erreur, p95 10,65 ms. Les deux phases sont séparées de 10,90 secondes et couvrent 88,1 % de la durée de la suite finale. Mesures locales, cache chaud ; aucune extrapolation de capacité en production.
  • Le test réel a reproduit un coût annulé réintroduit lors d’un réessai (total remontant de 3 € à 5 €). La garde sur les lignes déjà annulées corrige ce cas : total final 3 €, ligne annulée à 0 €, remboursement et retour de stock effectués une seule fois. Vérifié avec « Enregistrer », « Terminer », une nouvelle ouverture, puis dans la page complète du comptoir.
  • Vérification visuelle et validation d’une transaction dans la preview locale avec le vrai backend et une base fictive : fermeture immédiate et liste disponible. Démo locale supplémentaire des états succès et erreur avec les vrais composants et une API simulée, vérification visuelle du nouveau rendu.

Related issues :

Remplace #193 sur la branche feat/transactions-notifications. Suite au problème de modale restant après #192. Aucune issue liée.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Documentation (update or create documentation)
  • CI/CD
  • Other
  • Breaking change (fix or feature that would cause existing functionality to change)

@lmandrelli lmandrelli added bug Something isn't working enhancement New feature or request labels Sep 19, 2026
@lmandrelli lmandrelli changed the title feat(uc): enhance notifications on a modified transaction feat(ux): enhance notifications on a modified transaction Sep 19, 2026
@lmandrelli
lmandrelli force-pushed the feat/transactions-notifications branch from 23c05e9 to c146c19 Compare September 19, 2026 14:34
@lmandrelli
lmandrelli force-pushed the feat/transactions-notifications branch from c146c19 to e2918f0 Compare September 19, 2026 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant