Namespacing schematu

Spraw, aby wszystkie typy i interfejsy dodawane do schematu przez wtyczki były automatycznie objęte przestrzenią nazw.

Namespacing schematu pozwala uniknąć konfliktów nazw, które powstają, gdy różni właściciele (np. różne zespoły w firmie lub wtyczki firm trzecich) używają tej samej nazwy dla typu lub interfejsu.

Na przykład załóżmy, że firma "AwesomeWP" ma zespół Tutoriali i zespół Sprzedaży, a obydwa tworzą typ Product dla schematu GraphQL firmy, co powoduje konflikt.

Stosując namespacing do schematu, oba typy zostałyby automatycznie przekształcone w AwesomeWPTutorialsProduct i AwesomeWPSalesProduct, eliminując konflikt bez konieczności ręcznej modyfikacji schematu ani interakcji między zespołami.

Encje modelu danych WordPress nie otrzymują przestrzeni nazw

Model danych WordPress jest uznawany za kanoniczny, a jego typy schematu GraphQL (takie jak Post i User) oraz interfejsy (takie jak Commentable i WithMeta) nie otrzymują przestrzeni nazw.

Namespacing schematu w endpointach

Istnieją 2 poziomy, na których możemy określić, czy schemat będzie miał przestrzeń nazw. W kolejności priorytetu:

1. W konfiguracji schematu

Namespacing schematu dla niestandardowego endpointu lub persisted query można zdefiniować poprzez odpowiednią konfigurację schematu:

Namespacing, ustawiony w konfiguracji schematu

2. Tryb domyślny, zdefiniowany w Ustawieniach

Jeśli konfiguracja schematu ma wartość "Default", zostanie użyty tryb zdefiniowany w Ustawieniach:

Wizualizacja schematu z przestrzenią nazw

Użyj klienta Voyager, aby zwizualizować schemat z przestrzenią nazw.

Gdy namespacing jest wyłączony, schemat WordPress wygląda następująco:

Interaktywny schemat

Gdy jest włączony, typy i interfejsy dodane przez wtyczki otrzymują przestrzeń nazw i wyglądają tak:

Interaktywny schemat z przestrzenią nazw

Zapytania o nazwy typów (bez) przestrzeni nazw

Po włączeniu namespacingu typy można odpytywać zarówno przy użyciu nazwy z przestrzenią nazw, jak i bez niej. Dlatego tylko queries dotyczące typów powodujących konflikt wymagają edycji, a nie wszystkie.

Na przykład, jeśli zespół Sprzedaży AwesomeWP ma również typ Discount, query o tę nazwę typu nadal działa:

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

Tylko konfliktujący typ Product powinien zostać zaktualizowany do AwesomeWPSalesProduct w query, aby usunąć wszelką niejednoznaczność:

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

Specyfikacja GraphQL

Ta funkcjonalność nie jest obecnie częścią specyfikacji GraphQL, ale została zgłoszona w:

Issue #163 - Namespaces.