Пространства имён в схеме для предотвращения конфликтов

Разработчики, публикующие плагины в каталоге WordPress, заранее не знают, кто будет использовать их плагины и какую конфигурацию/среду будет иметь сайт, в том числе какие другие плагины могут быть установлены. Вследствие этого плагин должен быть подготовлен к конфликтам и заблаговременно стараться их предотвратить.

Один из способов, которым WordPress-плагины избегают конфликтов, — это пространства имён PHP. Namespace'ы широко используются в PHP-сообществе, следуя стандарту PHP Standard Recommendation PSR-4 для обеспечения автозагрузки Composer. PHP-пакеты должны включать имя вендора в виде "vendor-name/package-name", и соответствующий namespace присутствует в PHP-коде:

<?php
namespace VendorName\PackageName\ClassName;

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

Наличие двух типов с одинаковым именем
Наличие двух полей одного типа с одинаковым именем
Наличие двух директив с одинаковым именем

Пространства имён были запрошены для спецификации GraphQL:

At the moment all GraphQL types share one global namespace. This is also true for all of the fields in mutation/subscription type. It can be a concern for bigger projects which may contain several loosely-coupled parts in a GraphQL schema.

Тем не менее Ли Байрон (один из создателей GraphQL во время работы в Facebook) считает, что добавлять пространства имён в спецификацию не оправдано. В этом комментарии он объясняет, как Facebook управляет тысячами типов в своей схеме GraphQL без конфликтов:

We avoid naming collisions in two ways:

integration tests.

We don't allow any commit to merge into our repository that would result in a broken GraphQL schema. [...]

Common naming patterns.

We have common patterns for naming things which naturally avoid collision problems. [...]

Однако тот факт, что эта стратегия работает для Facebook, не означает, что она сработает в WordPress: поскольку Facebook контролирует все входные данные своей схемы GraphQL, он может позволить себе следовать процедуре именования сущностей, гарантируя отсутствие конфликтов. Но WordPress-сайт в значительной мере зависит от сторонних плагинов и не контролирует, как эти плагины создаются.

Например, если сайт использует плагины WooCommerce и Easy Digital Downloads, и оба имеют тип Product для схемы GraphQL, возникнет конфликт. Единственный выход для владельца сайта — обратиться к одной из компаний и попросить изменить их код. Это не профилактика, а исправление, и такой подход ненадёжен.

Пространства имён позволяют владельцам WordPress-сайтов быть уверены, что их код всегда будет работать. Если два типа имеют имя Product, администратор сайта может включить пространства имён в схеме GraphQL, и эти типы будут автоматически переименованы в WooCommerce_Product и EDD_Product, что устранит конфликт.

В качестве дополнительного преимущества пространства имён делают схему GraphQL более элегантной: если WooCommerce хочет гарантировать, что с его плагином никогда не возникнет конфликтов, он вынужден «добавлять namespace» прямо в имя типа: WCProduct, WCDownload и WCPayment (или, чтобы быть абсолютно уверенным, что это всегда будет работать, он мог бы назвать их WooCommerceProduct, WooCommerceDownload и WooCommercePayment). Благодаря пространствам имён эти типы могут иметь более естественные названия: Product, Download и Payment.