Пространства имён схемы

Все типы и интерфейсы, добавляемые в схему плагинами, автоматически получают пространства имён.

Применение пространств имён к схеме позволяет избежать конфликтов имён, которые возникают, когда разные владельцы (например, разные команды в компании или сторонние плагины) используют одно и то же имя для типа или интерфейса.

Допустим, компания «AwesomeWP» имеет команду по обучению и команду продаж, и обе создают тип Product для GraphQL-схемы компании, что порождает конфликт.

При применении пространств имён к схеме оба типа автоматически преобразуются в AwesomeWPTutorialsProduct и AwesomeWPSalesProduct, что устраняет конфликт без ручного изменения схемы и без необходимости взаимодействия команд друг с другом.

​

Сущности модели данных WordPress не получают пространства имён

Модель данных WordPress считается канонической, и её типы GraphQL-схемы (такие как Post и User) и интерфейсы (такие как Commentable и WithMeta) не получают пространства имён.

​

Применение пространств имён к схеме в эндпоинтах

Существует 2 уровня, на которых можно определить, будет ли схема использовать пространства имён. В порядке приоритета:

​

1. В конфигурации схемы

Применение пространств имён для custom endpoint или persisted query можно задать через соответствующую конфигурацию схемы:

​

2. Режим по умолчанию, определённый в настройках

Если конфигурация схемы имеет значение "Default", будет использован режим, определённый в настройках:

​

Визуализация схемы с пространствами имён

Используйте клиент Voyager для визуализации схемы с пространствами имён.

Когда пространства имён отключены, схема WordPress выглядит следующим образом:

Когда они включены, типы и интерфейсы, добавленные плагинами, получают пространства имён и выглядят так:

​

Запросы к типам с пространствами имён и без них

После включения пространств имён типы можно запрашивать как с использованием пространства имён, так и без него. Поэтому редактировать нужно только те queries, которые затрагивают конфликтующие типы, а не все queries.

Например, если команда продаж AwesomeWP также имеет тип Discount, запрос, обращающийся к этому типу, по-прежнему работает:

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

Только конфликтующий тип Product следует обновить до AwesomeWPSalesProduct в запросе, чтобы устранить неоднозначность:

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

​

Спецификация GraphQL

Данная функциональность в настоящее время не входит в спецификацию GraphQL, однако была запрошена здесь:

• Issue #163 - Namespaces.