Fonctionnalités personnalisées pour le schéma

De nombreuses fonctionnalités proposées pour la spécification GraphQL sont déjà implémentées dans Gato GraphQL, il n'est donc pas nécessaire d'attendre.

​

Namespacing du schéma

Si les plugins WooCommerce et Easy Digital Downloads implémentaient tous les deux un type Product pour l'API GraphQL, nous ne pourrions pas installer les deux plugins en même temps, car leurs types entreraient en conflit.

Le namespacing du schéma permet d'éviter les conflits dans le schéma en appliquant un namespace à tous les noms de types. Ainsi, le type Product deviendrait respectivement Woo_Product et EDD_Product, et ces types pourraient être ajoutés au même schéma.

Cette image montre un schéma avec namespacing, dans lequel le préfixe EM_ a été ajouté aux types Event et Location pour éviter les collisions de noms :

​

Champs globaux

Les champs globaux sont des champs accessibles depuis n'importe quel type du schéma GraphQL (tout en n'étant définis qu'une seule fois).

Le schéma GraphQL expose des types, comme Post, User et Comment, et les champs disponibles pour chaque type, comme Post.title, User.name et Comment.responses. Ces champs traitent des « données », car ils récupèrent un élément de données spécifique d'une entité.

Gato GraphQL offre en outre un autre type de champs : ceux qui fournissent des « fonctionnalités » plutôt que des données.

Quelques exemples de champs globaux :

• _not
• _if
• _equals
• _isEmpty
• _echo
• _sprintf
• _arrayItem
• _arrayAddItem
• _arrayUnique
• et bien d'autres

Les champs de fonctionnalité sont utiles pour obtenir des données stockées en dehors de WordPress et pour manipuler les données une fois récupérées, nous permettant de transformer la valeur d'un champ de la manière requise, et nous offrant de puissantes capacités d'import/export de données.

Les champs de fonctionnalité n'appartiennent pas à un type spécifique, comme Post ou User, mais à tous les types du schéma. C'est pourquoi ils sont gérés de manière distinctive dans Gato GraphQL, sous le nom de « champs globaux ».

​

Field to input

Obtenez la valeur d'un champ, manipulez-la et passez-la en entrée d'un autre champ, le tout dans la même requête.

query {
  posts {
    excerpt
 
    # Referencing previous field with name "excerpt"
    isEmptyExcerpt: _isEmpty(value: $__excerpt)
 
    # Referencing previous field with alias "isEmptyExcerpt"
    isNotEmptyExcerpt: _not(value: $__isEmptyExcerpt)
  }
}Copy

​

Directives composables

Souvent, une directive ne peut pas être appliquée à un champ parce qu'elle possède une entrée différente de la sortie du champ. Par exemple, la directive @strUpperCase reçoit une chaîne en entrée, elle ne peut donc pas être appliquée au champ User.capabilities, qui retourne un tableau de chaînes.

Avec les directives composables, une directive peut augmenter une autre directive pour modifier son comportement ou combler une lacune. Cela supprime la nécessité de dupliquer des champs ou des directives juste pour changer leurs types d'entrée ou de retour, évitant ainsi la surcharge.

Dans cette requête, la directive @underEachArrayItem itère sur un tableau de chaînes et applique sa directive imbriquée @strUpperCase à chacune d'elles, résolvant l'incompatibilité de types :

query {
  users {
    capabilities
      @underEachArrayItem
        @strUpperCase
  }
}Copy

​

Directives multi-champs

Appliquez des directives à plusieurs champs (au lieu d'un seul), pour améliorer les performances et élargir les cas d'utilisation.

Lorsqu'elle est activée, un argument affectAdditionalFieldsUnderPos est ajouté à toutes les directives, permettant de spécifier les positions relatives des champs supplémentaires auxquels appliquer la directive.

Par exemple, dans la requête suivante, la directive @strTranslate est appliquée uniquement au champ content :

query {
  posts {
    excerpt
    content @strTranslate
  }
}Copy

Le champ excerpt peut également recevoir la directive @strTranslate, en ajoutant l'argument de directive affectAdditionalFieldsUnderPos avec la valeur [1] (car 1 est la position relative du champ excerpt par rapport à la directive @strTranslate) :

query {
  posts {
    excerpt
    content
      @strTranslate(
        affectAdditionalFieldsUnderPos: [1]
      )
  }
}Copy

​

Versionnage par champ et par directive

Versionnez les champs et les directives indépendamment du schéma.

Au lieu de faire évoluer l'ensemble du schéma (ce qui oblige à modifier le nom du champ ou de la directive modifié·e), nous pouvons :

• Conserver différentes implémentations sous le même nom de champ ou de directive
• Exposer l'implémentation héritée sous un tag, en utilisant le versionnage sémantique
• Accéder à une version spécifique via l'argument de champ/directive versionConstraint

​

Retour proactif

Utilisez l'entrée de premier niveau extensions pour envoyer des données concernant les dépréciations et les avertissements dans la réponse à la requête.

• Dépréciations : Les dépréciations sont retournées dans la même requête impliquant des champs dépréciés, et pas seulement lors de l'introspection.
• Avertissements : Les avertissements sont des problèmes pouvant être considérés comme non bloquants, c'est-à-dire qu'ils améliorent la requête sans la rompre.

Par exemple, la requête suivante exporte deux champs en utilisant le même nom de variable dynamique "prop", ce qui génère un avertissement :

query {
  posts {
    excerpt @export(as: "prop")
    content @export(as: "prop")
  }
}Copy

La réponse inclura la section warnings (sous extensions) avec un message correspondant :

{
  "extensions": {
    "warnings": [
      {
        "message": "Dynamic variable with name 'props' had already been set, had its value overridden",
        "locations": [
          {
            "line": 4,
            "column": 25
          }
        ]
      }
    ]
  },
  "data": {
    "posts": {
      "excerpt": "Hello world!",
      "Content": "<p>Hello world!</p>"
    }
  }
}Copy