Namespacing van het schema

Zorg dat alle typen en interfaces die door plug-ins aan het schema worden toegevoegd, automatisch worden voorzien van een naamruimte.

Namespacing van het schema voorkomt naamconflicten, die ontstaan wanneer verschillende eigenaren (bijv. verschillende teams in het bedrijf of externe plug-ins) dezelfde naam gebruiken voor een type of interface.

Stel je voor dat bedrijf "AwesomeWP" een Tutorials-team en een Verkoop-team heeft, en dat beide teams een Product-type aanmaken voor het GraphQL-schema van het bedrijf, wat een conflict veroorzaakt.

Door namespacing op het schema toe te passen, worden de twee typen automatisch omgezet naar AwesomeWPTutorialsProduct en AwesomeWPSalesProduct, waarmee het conflict wordt opgelost zonder het schema handmatig te hoeven aanpassen of de teams met elkaar te laten overleggen.

​

De entiteiten van het WordPress-datamodel krijgen geen naamruimte

Het WordPress-datamodel wordt als canoniek beschouwd, en de GraphQL-schematypen (zoals Post en User) en interfaces (zoals Commentable en WithMeta) krijgen geen naamruimte.

​

Namespacing van het schema in de endpoints

Er zijn 2 niveaus waarop je kunt instellen of het schema een naamruimte krijgt. In volgorde van prioriteit:

​

1. In de schemaconfiguratie

Namespacing van het schema voor een aangepast endpoint of persisted query kan worden ingesteld via de bijbehorende schemaconfiguratie:

​

2. Standaardmodus, gedefinieerd in de Instellingen

Als de schemaconfiguratie de waarde "Default" heeft, wordt de modus gebruikt die in de Instellingen is gedefinieerd:

​

Het schema met naamruimte visualiseren

Gebruik de Voyager-client om het schema met naamruimte te visualiseren.

Wanneer namespacing is uitgeschakeld, ziet het WordPress-schema er zo uit:

Wanneer het is ingeschakeld, krijgen de typen en interfaces die door plug-ins zijn toegevoegd een naamruimte en zien ze er zo uit:

​

Queries uitvoeren op (niet-)genaamruimde typenamen

Zodra namespacing is ingeschakeld, kunnen typen worden bevraagd met zowel hun genaamruimde als niet-genaamruimde typenamen. Daarom hoeven alleen queries die betrekking hebben op conflicterende typen te worden aangepast, en niet alle queries.

Als het Verkoop-team van AwesomeWP bijvoorbeeld ook een Discount-type heeft, werkt een query voor die typenaam nog steeds:

query {
  discounts {
    ...DiscountProps
  }
}
 
fragment DiscountProps on Discount {
  price
  dateRange
}Copy

Alleen het conflicterende type Product moet in de query worden bijgewerkt naar AwesomeWPSalesProduct om eventuele onduidelijkheid weg te nemen:

query {
  products {
    ...ProductProps
  }
}
 
fragment ProductProps on AwesomeWPSalesProduct {
  price
  dateRange
}Copy

​

GraphQL-specificatie

Deze functionaliteit maakt momenteel geen deel uit van de GraphQL-specificatie, maar is aangevraagd in:

• Issue #163 - Namespaces.