Les mises à jour optimistes fonctionnent mieux lorsque l'échec est facile à annuler_
L'interface utilisateur optimiste améliore la rapidité perçue en mettant à jour l'interface avant que le serveur ne confirme, mais cela ne semble positif que lorsque le retour en arrière est clair et que le risque de conflit est faible.
L'interface utilisateur optimiste est l'un des moyens les plus rapides de donner à un produit une sensation de réactivité sans réduire la latence du réseau. L'interface se met à jour immédiatement, puis l'appel au serveur prend le relais en arrière-plan. Quand cela fonctionne, l'expérience est nette. Quand cela échoue gravement, cela semble malhonnête.
C'est pourquoi la question architecturale n'est pas "devons-nous utiliser des mises à jour optimistes ?" mais "quelles mutations sont suffisamment sûres pour être prédites ?"
Une bonne mutation optimiste
Les actions à faible risque avec un retour en arrière simple sont les meilleurs candidats :
aimer un post
basculer un paramètre
réorganiser une liste locale
ajouter un élément de brouillon qui peut être supprimé facilement
La partie importante n'est pas l'écriture optimiste. C'est le chemin de retour en arrière.
Où cela devient risqué
L'interface utilisateur optimiste devient dangereuse lorsque :
les conflits sont courants
les règles commerciales vivent uniquement sur le serveur
de l'argent ou des stocks sont impliqués
l'échec est difficile à expliquer ou à annuler
Une confirmation de paiement ne devrait pas être "optimistiquement réussie". Un "like" social peut probablement l'être.
Meilleure règle
Utilisez des mises à jour optimistes là où l'échec est rare, le retour en arrière est clair, et l'utilisateur peut comprendre ce qui s'est passé si le serveur rejette le changement. Cela produit un produit rapide sans apprendre aux utilisateurs à se méfier de l'interface.