1
votes

Qu'est-ce que le flux de travail général avec l'application Typescript côté client et le backend GraphQL

J'ai une application React Typescript côté client. Et j'ai lu que c'était une bonne pratique de créer des interfaces pour les réponses provenant des points de terminaison.

Par exemple, le schéma GraphQL a déclaré ce type:

interface AuthorFullname {
  firstName: string;
  lastName: string;
}

Donc côté client, j'ai aussi besoin de créer une interface similaire:

const data = await getWholeAuthorFromGraphQL();
const user = data as IUser;

Et lorsque l'application cliente recevra une réponse, elle enverra simplement une réponse à cette interface, comme ceci:

interface Post: {...}

interface IAuthor {
  id: number;
  firstName: string;
  lastName: string;
  posts: Post[]
}

Mais une chose qui ne m'est pas claire est que GraphQL permet de récupérer champs spécifiques au lieu de l'objet entier.

Par exemple, dans un autre lieu d'application, j'ai également besoin d'un objet IUser , mais uniquement avec 2 champs: firstName et secondName code >. Dois-je créer une autre interface dans ce cas? Comme:

type Author {
  id: Int!
  firstName: String!
  lastName: String!
  ... {more fields}
  posts(findTitle: String): [Post]
}

Ou puis-je simplement diffuser vers IUser tout ce qui appartient au type GQL Author ? Et puis dans le code je ferai attention car je saurai que l'objet user ne contient que firstName et lastName . Je n'utiliserai donc pas d'autres champs que firstName et lastName .


0 commentaires

3 Réponses :


0
votes

C'est une excellente question, étant donné que l'interface GraphQL peut potentiellement renvoyer des versions partielles de l'interface, il vaut mieux utiliser des types HOC Typescript comme Partial

// assume the following
interface MyModel {
 field1: string;
 field2: string;
}




const item = myNetworkCall()
if(item.field1){
 // etc
}

Partiel dans cette instance fera chaque attribut est facultatif, ce qui signifie que vous pouvez effectuer une vérification d'existence sur le site d'appel réel pour la réponse. Ceci est particulièrement utile si vous avez défini Typescript en mode strict.

Alternativement, vous pourriez avoir votre appel

function myNetworkCall() : Partial<MyModel>

Ce qui applique encore la même chose, vous doivent faire le gros du travail pour s'assurer que les champs que vous recherchez existent (en vérifiant l'existence)

const getResult : Partial<MyModel> = await yourNetworkRequest()


0 commentaires

1
votes

Si vous acceptez d'avoir généré du code, sur votre application cliente, vous pouvez utiliser un outil appelé apollo codegen .

Fondamentalement, il vérifie chaque endroit où vous avez défini vos requêtes gql et, avec la définition du schéma du serveur, il génère les Interfaces nécessaires pour le requêtes définies. Donc, si vous définissez des requêtes imbriquées ou des requêtes avec des fragments, cela générera simplement les interfaces dont vous avez besoin pour les exécuter.

Voici également un bon article sur Générer des définitions TypeScript pour les requêtes GraphQL .


0 commentaires

0
votes

Une approche consiste simplement à créer des interfaces spécifiques à chaque requête que vous utilisez réellement dans votre code. Par exemple, étant donné deux requêtes:

interface QueryAAuthor {
  id: number;
  firstName: string;
  lastName: string;
  posts: QueryAPost[];
}

interface QueryBAuthor {
  id: number;
  firstName: string;
  lastName: string;
}

Nous pouvons simplement créer deux interfaces distinctes, une pour chaque requête:

query QueryA {
  allAuthors {
    id
    firstName
    lastName
    posts {
      ...PostFields
    }
  }
}

query QueryB {
  id
  firstName
  lastName
}

Bien que cela crée plus d'interfaces et génère une complexité supplémentaire dans votre code, cela signifie également qu'il n'y a pas d'ambiguïté lorsque vous travaillez avec le résultat d'une requête. Par exemple, si nous devions utiliser une seule interface avec Partial à la place, je pourrais toujours faire référence à des publications même en traitant avec le résultat de QueryB et le compilateur ne l'attraperait pas. p>

Il s'agit en fait de l'approche utilisée par la fonction codegen de Apollo CLI , qui vous permet de générer des types en fonction d'un schéma et de vos requêtes côté client.

Je ne pense pas que ce soit la seule façon de le gérer - c'est juste une question de combien de sécurité de type vous voulez dans votre code.


0 commentaires