Namespacing des Schemas
Sorge dafür, dass alle Typen und Interfaces, die von Plugins zum Schema hinzugefügt werden, automatisch einem Namespace zugewiesen werden.
Das Namespacing des Schemas vermeidet Namenskonflikte, die entstehen, wenn verschiedene Eigentümer (z. B. unterschiedliche Teams im Unternehmen oder Drittanbieter-Plugins) denselben Namen für einen Typ oder ein Interface verwenden.
Nehmen wir zum Beispiel an, das Unternehmen „AwesomeWP" hat ein Tutorial-Team und ein Verkaufsteam, und beide erstellen einen Product-Typ für das GraphQL-Schema des Unternehmens – das erzeugt einen Konflikt.
Durch das Namespacing des Schemas werden die beiden Typen automatisch in AwesomeWPTutorialsProduct und AwesomeWPSalesProduct umgewandelt, wodurch der Konflikt vermieden wird, ohne das Schema manuell anpassen oder die Teams miteinander koordinieren zu müssen.
Die Entitäten des WordPress-Datenmodells werden nicht namespace-qualifiziert
Das WordPress-Datenmodell gilt als kanonisch, und seine GraphQL-Schema-Typen (wie Post und User) sowie Interfaces (wie Commentable und WithMeta) werden nicht namespace-qualifiziert.
Namespacing des Schemas in den Endpunkten
Es gibt 2 Ebenen, auf denen du festlegen kannst, ob das Schema namespace-qualifiziert wird oder nicht. In Prioritätsreihenfolge:
1. In der Schema-Konfiguration
Das Namespacing des Schemas für einen Custom Endpoint oder eine Persisted Query kann über die entsprechende Schema-Konfiguration festgelegt werden:

2. Standardmodus, in den Einstellungen festgelegt
Wenn die Schema-Konfiguration den Wert "Default" hat, wird der in den Einstellungen festgelegte Modus verwendet:

Das Schema mit Namespace visualisieren
Verwende den Voyager-Client, um das Schema mit Namespace zu visualisieren.
Wenn das Namespacing deaktiviert ist, sieht das WordPress-Schema so aus:

Wenn es aktiviert ist, werden die von Plugins hinzugefügten Typen und Interfaces namespace-qualifiziert und sehen so aus:

Typen mit und ohne Namespace abfragen
Sobald das Namespacing aktiviert ist, können Typen sowohl über ihren namespace-qualifizierten als auch über ihren nicht-qualifizierten Namen abgefragt werden. Daher müssen nur queries, die konfliktbehaftete Typen betreffen, angepasst werden – nicht alle.
Wenn das Verkaufsteam von AwesomeWP beispielsweise auch einen Discount-Typ hat, funktioniert eine query, die diesen Typnamen abfragt, weiterhin:
query {
discounts {
...DiscountProps
}
}
fragment DiscountProps on Discount {
price
dateRange
}Nur der konfliktbehaftete Typ Product sollte in der query auf AwesomeWPSalesProduct aktualisiert werden, um jede Mehrdeutigkeit zu beseitigen:
query {
products {
...ProductProps
}
}
fragment ProductProps on AwesomeWPSalesProduct {
price
dateRange
}GraphQL-Spezifikation
Diese Funktionalität ist derzeit nicht Teil der GraphQL-Spezifikation, wurde aber angefragt in: