Cache Apollo : normalisation et mises à jour

InMemoryCache stocke chaque objet à l'aide d'une clé de cache composée de __typename et d'id : User:1, Post:42. Lorsqu'une requête renvoie un User avec l'id « 1 », celui-ci n'est stocké qu'une seule fois sous cette clé, quel que soit le nombre de requêtes différentes qui l'incluent.

Toute requête ultérieure qui récupère le même User:1 lit l'entrée unique du cache, ce qui garantit que tous les composants voient les mêmes données.

Lorsqu'une mutation renvoie un objet User:1 mis à jour, Apollo l'écrit dans l'entrée de cache User:1. Toute requête active qui incluait User:1 reflète automatiquement les champs mis à jour dans l'interface, sans code supplémentaire.

Cette propagation automatique constitue le principal avantage d'un cache normalisé par rapport à un cache fondé sur les documents (indexé par requête).

Lisez le résultat actuellement mis en cache d'une requête : cache.readQuery({ query: GET_USERS }) renvoie l'objet de données comme si useQuery l'avait renvoyé. Renvoie null si la requête ne se trouve pas dans le cache.

Utilisez readQuery dans les fonctions de mise à jour des mutations pour lire la liste actuelle avant de la modifier.

cache.writeQuery({ query: GET_USERS, data: { users: updatedUsers } }) écrit directement dans le cache et déclenche un nouveau rendu de tous les composants qui lisent GET_USERS. Aucune requête réseau n'est effectuée.

Combinez readQuery et writeQuery pour implémenter des mises à jour immuables du cache : lisez, produisez un nouveau tableau, puis réécrivez-le.

cache.modify({ id: cache.identify(user), fields: { name: () => 'New Name' } }) modifie directement les champs d'une entité précise du cache. Il n'est pas nécessaire de lire d'abord une requête lorsque vous connaissez l'ID de cache de l'entité.

L'objet qui contient les champs associe les noms de champs à des fonctions de modification qui reçoivent la valeur actuelle et renvoient la nouvelle valeur.

Transmettez une fonction de mise à jour à useMutation : useMutation(ADD_POST, { update(cache, { data: { addPost } }) { cache.modify({ id: cache.identify(user), fields: { posts: existingPosts => [...existingPosts, addPost] } }); } }).

Cette opération ajoute la nouvelle publication au tableau des publications de l'utilisateur mis en cache et met à jour tous les composants qui affichent sa liste de publications.

cache.evict({ id: 'User:1' }) supprime l'entrée User:1 du cache. Toute requête active qui incluait User:1 sera de nouveau rendue sans cette entité dans son résultat.

Après avoir supprimé des entrées, appelez cache.gc() pour supprimer les objets qui ne sont plus accessibles depuis les requêtes racines. Cela évite les fuites de mémoire dans les applications exécutées pendant longtemps.

cache.gc() parcourt le graphe du cache à partir de toutes les requêtes actives et supprime les entités qui ne sont plus accessibles. Vous pouvez l'appeler régulièrement ou après des mutations groupées qui suppriment de nombreuses entités.

Les entités référencées par des appels useQuery actifs ne sont jamais récupérées, seules les entités orphelines qui ne font plus partie d'aucun résultat de requête le sont.

Si vous interrogez une entité unique (GET_USER par identifiant) qui est déjà mise en cache dans le cadre d'une requête de liste, Apollo peut la lire depuis le cache sans aller-retour réseau grâce aux politiques de champs : keyArgs et aux fonctions read de la politique de type.

La fonction read renvoie une référence de cache : return toReference({ __typename: 'User', id: args.id }), ce qui indique à Apollo de lire l'entrée de cache User:id existante.

Si vos entités utilisent un champ autre que id comme clé unique (par exemple, slug ou uuid), configurez-le dans la politique de type : new InMemoryCache({ typePolicies: { Post: { keyFields: ['slug'] } } }).

Apollo utilise alors Post:my-post-slug comme clé de cache au lieu d'exiger un champ id, ce qui préserve la normalisation pour les schémas non standard.

refetchQueries: [{ query: GET_USERS }] dans les options de useMutation déclenche une nouvelle requête réseau une fois la mutation terminée. Cette solution est plus simple, mais elle effectue toujours une requête réseau.

La fonction de mise à jour modifie le cache localement et évite l'aller-retour réseau. Utilisez refetchQueries lorsque la logique de mise à jour du cache est trop complexe à écrire ou lorsque des champs calculés par le serveur rendent les mises à jour locales du cache peu fiables.

Quel est le format de clé de cache par défaut utilisé par InMemoryCache pour stocker les entités ?

InMemoryCache normalise les entités avec __typename+id, ce qui permet les mises à jour automatiques entre les requêtes. Lisez et écrivez dans le cache avec cache.readQuery, cache.writeQuery et cache.modify. Supprimez les entités avec cache.evict, puis cache.gc. Configurez des champs de clé personnalisés via typePolicies pour les clés primaires qui n'utilisent pas id.

Utilisez les fonctions de mise à jour des mutations pour optimiser l'efficacité du cache local ; utilisez refetchQueries lorsque les champs calculés par le serveur rendent les mises à jour locales peu fiables.