almessadi.
Retour à l'index

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.

Publié2 décembre 2024
Temps de lecture6 min read

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

Avec TanStack Query, le modèle est explicite :

const mutation = useMutation({
  mutationFn: updateTodo,
  onMutate: async (nextTodo) => {
    await queryClient.cancelQueries({ queryKey: ["todos"] });
    const previous = queryClient.getQueryData<Todo[]>(["todos"]);

    queryClient.setQueryData<Todo[]>(["todos"], (current = []) =>
      current.map((todo) => (todo.id === nextTodo.id ? nextTodo : todo)),
    );

    return { previous };
  },
  onError: (_error, _nextTodo, context) => {
    queryClient.setQueryData(["todos"], context?.previous);
  },
});

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.

Lectures complémentaires