Fragments GraphQL : laissez chaque composant être propriétaire de ses données

Les requêtes GraphQL semblent propres au début. Une seule requête récupère toutes vos données. Puis, votre application grandit.

Votre requête de page commence à collecter des champs pour de nombreux composants enfants différents. Vous ajoutez un champ pour un nouveau composant. Six semaines plus tard, vous supprimez ce composant. Vous oubliez de retirer le champ de la requête principale. Désormais, personne ne sait s'il est sûr de le supprimer. La requête ne cesse de croître.

Les fragments règlent ce problème. La plupart des équipes les utilisent comme un moyen de copier-coller des champs. C'est une mauvaise approche. Les fragments devraient être un modèle de propriété de composant.

Un fragment est un groupe de champs nommé pour un type spécifique.

Exemple : fragment UserBadge on User { id name avatarUrl }

Vous utilisez l'opérateur spread de ce fragment dans toute requête ayant besoin d'un User.

La véritable valeur réside dans l'endroit où vous enregistrez le fragment. Ne les placez pas dans un fichier partagé. Placez le fragment dans le même fichier que le composant qui l'utilise.

C'est ce qu'on appelle la co-localisation (co-location). Chaque composant déclare ses propres besoins en données.

Lorsqu'un composant a besoin d'un nouveau champ, vous l'ajoutez à son fragment. La requête parente se met à jour automatiquement. Lorsque vous supprimez un composant, vous supprimez son fragment. La requête rétrécit. Le composant parent n'a pas besoin de connaître les champs internes de ses enfants.

Le masquage de données (data masking) rend cela encore meilleur. Avec le masquage activé, un composant ne voit que les champs qu'il a demandés dans son propre fragment. Même si le serveur envoie des données supplémentaires, votre composant ne peut pas y accéder.

Cela crée un contrat strict.

  • TypeScript sait exactement quelles données chaque composant possède.
  • Si vous supprimez un champ d'un fragment, TypeScript vous affiche toutes les erreurs.
  • Le refactoring devient une simple vérification de type au lieu d'une recherche dans toute votre base de code.

Utilisez des fragments lorsque :

  • Plusieurs composants utilisent le même type comme User ou Product.
  • Vos requêtes de page sont trop longues.
  • Vous laissez accidentellement des champs inutilisés dans vos requêtes.
  • Vous voulez la sécurité de TypeScript pour vos données.

Commencez petit. Trouvez un composant qui récupère des données d'une requête parente. Déplacez ses champs dans un fragment. Placez ce fragment dans le fichier du composant.

Les fragments garantissent que votre récupération de données correspond à votre interface utilisateur à mesure que votre application grandit.

Source : https://dev.to/grimicorn/graphql-fragments-let-each-component-own-its-data-5359