Implémenter manuellement des mises à jour optimistes

Les mises à jour optimistes manuelles commencent par l'état local du composant, initialisé à partir des données du serveur : const [items, setItems] = useState(serverItems). C'est cet état local que vous affichez et que vous modifiez de manière optimiste. Vous ne devez NOT modifier directement les données récupérées du serveur : conservez une copie locale que vous contrôlez.

Lorsque l'utilisateur déclenche une modification (en cliquant sur « Ajouter », « J'aime » ou « Supprimer »), effectuez immédiatement la mise à jour de l'état avant d'appeler l'API : setItems(prev => [...prev, newItem]). L'interface reflète instantanément le changement. Ce n'est qu'après cette mise à jour que vous lancez la véritable requête réseau.

Avant d'effectuer la mise à jour optimiste, capturez l'état actuel : const previousItems = items. Cet instantané est la cible de votre restauration. Si l'appel à l'API échoue, vous restaurez cette valeur. Stockez-la dans une variable (et non dans l'état), puisque vous n'en avez besoin que pendant la durée de la modification en attente.

Après la mise à jour optimiste, effectuez l'appel à l'API de manière asynchrone. Placez-le dans un bloc try/catch. En cas de réussite, vous pouvez éventuellement récupérer de nouveau les données pour les synchroniser avec l'état du serveur, ou faire confiance à l'état optimiste si le serveur renverrait les mêmes données. En cas d'échec, utilisez l'état précédent capturé pour effectuer la restauration.

Dans le bloc catch de votre modification : setItems(previousItems). Cela restaure l'état tel qu'il était avant la mise à jour optimiste. Affichez ensuite une notification d'erreur. Les utilisateurs comprennent que des échecs rares peuvent survenir ; ce qu'ils ne tolèrent pas, c'est une incohérence silencieuse.

Après la restauration, affichez un message d'erreur : « Impossible d'enregistrer les modifications. Veuillez réessayer. » avec un bouton Réessayer qui relance la même modification. Les utilisateurs gardent ainsi le contrôle. L'association restauration + notification d'erreur + nouvelle tentative gère élégamment l'échec sans bloquer toute l'interface.

Lorsque vous ajoutez un nouvel élément de manière optimiste, le serveur ne lui a pas encore attribué d'identifiant réel. Créez un identifiant temporaire pour l'élément optimiste : const tempId = crypto.randomUUID(). Utilisez-le comme clé de l'élément dans la liste. Une fois la réponse de l'API reçue avec succès, remplacez l'identifiant temporaire par l'identifiant réel attribué par le serveur.

Après la réussite de la modification de création, le serveur renvoie l'identifiant réel. Mettez à jour votre état pour remplacer l'élément temporaire : setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Cette réconciliation garantit que les opérations suivantes utilisent le bon identifiant serveur.

Si l'utilisateur déclenche deux modifications à la suite, les réponses peuvent arriver dans le désordre. La réponse de la seconde modification peut arriver avant celle de la première, et la restauration de la première peut écraser l'état correct produit par la seconde. Il s'agit d'une condition de concurrence propre aux interfaces optimistes.

Une solution aux conditions de course consiste à sérialiser les mutations à l’aide d’une file d’attente. Tant qu’une mutation est en cours, désactivez le bouton déclencheur (en définissant l’état isSubmitting sur vrai). N’autorisez la mutation suivante qu’une fois la précédente terminée. Cela réduit quelque peu la réactivité, mais garantit l’ordre correct des mises à jour de l’état.

Pour les opérations de suppression : capturez les éléments précédents, retirez de l’état l’élément supprimé, appelez l’API de suppression, puis annulez l’opération en cas d’échec. La suppression est plus simple que la création (aucune résolution d’ID n’est nécessaire), mais les mêmes principes s’appliquent. Envisagez d’ajouter un bref délai avant la suppression (en affichant une option « annuler ») avant d’appeler l’API.

Pourquoi les éléments ajoutés de manière optimiste ont-ils besoin d’un ID temporaire ?

Le schéma manuel : capturez previousItems, utilisez setItems avec le nouvel état, appelez l’API, annulez l’opération en cas d’échec avec setItems(previousItems) et affichez une erreur. Pour les ajouts, utilisez crypto.randomUUID() comme ID temporaire et remplacez-le par l’ID du serveur en cas de réussite. Évitez les conditions de course en désactivant le déclencheur pendant les mutations en cours. Annulation + notification + nouvelle tentative constituent l’expérience utilisateur standard en cas d’échec.