Benutzerdefinierte Funktionen für das Schema

Zahlreiche Funktionen, die für die GraphQL-Spezifikation vorgeschlagen wurden, sind in Gato GraphQL bereits implementiert – kein Warten nötig.

​

Schema-Namespacing

Wenn die Plugins WooCommerce und Easy Digital Downloads beide einen Typ Product für die GraphQL-API implementieren würden, könnten wir nicht beide Plugins gleichzeitig installieren, da ihre Typen in Konflikt geraten würden.

Schema-Namespacing ermöglicht es, Konflikte im Schema zu vermeiden, indem alle Typnamen mit einem Namespace versehen werden. So würde der Typ Product zu Woo_Product bzw. EDD_Product, und diese Typen könnten dem gleichen Schema hinzugefügt werden.

Dieses Bild zeigt ein Schema mit Namespacing, bei dem den Typen Event und Location das Präfix EM_ hinzugefügt wurde, um Namenskollisionen zu vermeiden:

​

Globale Felder

Globale Felder sind Felder, die unter jedem einzelnen Typ im GraphQL-Schema zugänglich sind (obwohl sie nur einmal definiert werden).

Das GraphQL-Schema stellt Typen bereit, wie Post, User und Comment, sowie die für jeden Typ verfügbaren Felder, wie Post.title, User.name und Comment.responses. Diese Felder befassen sich mit „Daten", da sie ein bestimmtes Datenstück aus einer Entität abrufen.

Gato GraphQL bietet darüber hinaus eine andere Art von Feldern: solche, die „Funktionalität" anstelle von Daten bereitstellen.

Einige Beispiele für globale Felder:

• _not
• _if
• _equals
• _isEmpty
• _echo
• _sprintf
• _arrayItem
• _arrayAddItem
• _arrayUnique
• und viele mehr

Funktionalitätsfelder sind nützlich, um Daten abzurufen, die außerhalb von WordPress gespeichert sind, und um die Daten nach dem Abruf zu manipulieren. Sie ermöglichen es uns, einen Feldwert auf beliebige Weise zu transformieren, und geben uns leistungsstarke Datenimport/-exportmöglichkeiten.

Funktionalitätsfelder gehören nicht zu einem bestimmten Typ wie Post oder User, sondern zu allen Typen im Schema. Deshalb werden sie in Gato GraphQL auf besondere Weise unter dem Namen „globale Felder" behandelt.

​

Field to input

Hole den Wert eines Felds, bearbeite ihn und übergib ihn als Eingabe an ein anderes Feld – alles innerhalb derselben query.

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

​

Komponierbare Direktiven

Häufig kann eine Direktive nicht auf ein Feld angewendet werden, weil ihre Eingabe sich vom Ausgabetyp des Felds unterscheidet. Zum Beispiel empfängt die Direktive @strUpperCase eine Zeichenkette als Eingabe, sodass sie nicht auf das Feld User.capabilities angewendet werden kann, das ein Array von Zeichenketten zurückgibt.

Mit komponier­baren Direktiven kann eine Direktive eine andere Direktive erweitern, um deren Verhalten zu ändern oder eine Lücke zu füllen. Dies beseitigt die Notwendigkeit, Felder oder Direktiven nur zur Änderung ihrer Eingabe- oder Rückgabetypen zu duplizieren, und vermeidet unnötigen Aufwand.

In dieser query iteriert die Direktive @underEachArrayItem über ein Array von Zeichenketten und wendet ihre verschachtelte Direktive @strUpperCase auf jede einzelne an, wodurch die Typinkompatibilität behoben wird:

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

​

Mehrfeld-Direktiven

Wende Direktiven auf mehrere Felder an (anstatt nur auf eines), für bessere Performance und erweiterte Anwendungsfälle.

Wenn aktiviert, wird allen Direktiven ein Argument affectAdditionalFieldsUnderPos hinzugefügt, mit dem die relativen Positionen der zusätzlichen Felder angegeben werden können, auf die die Direktive angewendet werden soll.

In der folgenden query wird die Direktive @strTranslate beispielsweise nur auf das Feld content angewendet:

query {
  posts {
    excerpt
    content @strTranslate
  }
}Copy

Das Feld excerpt kann ebenfalls die Direktive @strTranslate erhalten, indem das Direktiven-Argument affectAdditionalFieldsUnderPos mit dem Wert [1] hinzugefügt wird (da 1 die relative Position des Felds excerpt gegenüber der Direktive @strTranslate ist):

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

​

Feld- und direktiven­basierte Versionierung

Versioniere Felder und Direktiven unabhängig vom Schema.

Anstatt das gesamte Schema weiterzuentwickeln (was eine Änderung des Namens des geänderten Felds oder der Direktive erfordert), können wir:

• Verschiedene Implementierungen unter demselben Feld- oder Direktiven­namen behalten
• Die Legacy-Implementierung unter einem Tag mittels semantischer Versionierung bereitstellen
• Über das Feld-/Direktiven-Argument versionConstraint auf eine bestimmte Version zugreifen

​

Proaktives Feedback

Verwende den obersten Eintrag extensions, um Daten zu Deprecations und Warnungen in der Antwort auf die query zu senden.

• Deprecations: Deprecations werden in derselben query zurückgegeben, die veraltete Felder enthält, und nicht nur bei der Introspektion.
• Warnungen: Warnungen sind Probleme, die als nicht blockierend betrachtet werden können, d. h. sie verbessern die query, ohne sie zu unterbrechen.

Zum Beispiel exportiert die folgende query zwei Felder mit demselben dynamischen Variablennamen "prop", was eine Warnung erzeugt:

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

Die Antwort enthält den Abschnitt warnings (unter extensions) mit einer entsprechenden Meldung:

{
  "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