Actuellement, lorsqu'on édite une ressource, quand on appuie sur le bouton Sauvegarder, il se passe les étapes suivantes :
La page rebascule sur la vue Show de la ressource
Les données de la vue Show sont mises à jour en local seulement
[5 secondes s'écoulent]
La modification de la ressource est enregistrée en base de données
La vue se réactualise (avec potentiellement les anciennes données si la sauvegarde a échoué)
Ce mécanisme (par défaut dans react-admin) dit de "sauvegarde optimiste" est notamment prévu pour annuler aussitôt ses changements (mode undoable) et pour être plus fluide, mais pose également des problèmes UX et génère de la confusion auprès des utilisateurs, par exemple quand ceux-ci quittent la page ou la rechargent de manière trop précipité. Plusieurs cas de données mal sauvegardées ont été remontées sur des instances Archipelago, qui pourraient potentiellement venir de ce workflow complexe.
Je propose de passer en "sauvegarde pessimiste", permettant d'attendre que les modifications de la ressource soient bien enregistrées en base de données avant de basculer de page (comme la plupart des sites actuels). De plus, les modifications de ressources n'entraînant normalement pas une complexité de calcul ni un délai important, ça ne se justifie pas trop ici de faire du rendu optimiste à part faire de la sur-optimisation non-nécessaire.
Le fonctionnement du DeleteButton change avec la sauvegarde pessimiste. Désormais, il affiche une popup de confirmation lors de la suppression d'une ressource (ça permettra d'éviter de supprimer une ressource avec un missclick...)
Hello,
Actuellement, lorsqu'on édite une ressource, quand on appuie sur le bouton Sauvegarder, il se passe les étapes suivantes :
Ce mécanisme (par défaut dans react-admin) dit de "sauvegarde optimiste" est notamment prévu pour annuler aussitôt ses changements (mode undoable) et pour être plus fluide, mais pose également des problèmes UX et génère de la confusion auprès des utilisateurs, par exemple quand ceux-ci quittent la page ou la rechargent de manière trop précipité. Plusieurs cas de données mal sauvegardées ont été remontées sur des instances Archipelago, qui pourraient potentiellement venir de ce workflow complexe.
Je propose de passer en "sauvegarde pessimiste", permettant d'attendre que les modifications de la ressource soient bien enregistrées en base de données avant de basculer de page (comme la plupart des sites actuels). De plus, les modifications de ressources n'entraînant normalement pas une complexité de calcul ni un délai important, ça ne se justifie pas trop ici de faire du rendu optimiste à part faire de la sur-optimisation non-nécessaire.
PR liée (mais pas dépendante) sur Semapps https://github.com/assemblee-virtuelle/semapps/pull/1209
Le fonctionnement du DeleteButton change avec la sauvegarde pessimiste. Désormais, il affiche une popup de confirmation lors de la suppression d'une ressource (ça permettra d'éviter de supprimer une ressource avec un missclick...)