Espaces de noms dans le schéma pour éviter les conflits

Les développeurs qui publient des extensions sur le répertoire WordPress ne savent pas à l'avance qui utilisera leurs extensions, ni quelle configuration/environnement aura le site, y compris quelles autres extensions pourraient être installées. Par conséquent, l'extension doit être préparée aux conflits, et tenter de les prévenir à l'avance.

L'une des façons dont les extensions WordPress évitent les conflits est via les espaces de noms PHP. Les namespaces sont largement utilisés au sein de la communauté PHP, suivant la recommandation standard PHP PSR-4 pour activer le chargement automatique de Composer. Les paquets PHP doivent inclure le nom du vendeur, comme "vendor-name/package-name", et le namespace correspondant est présent dans le code PHP :

<?php
namespace VendorName\PackageName\ClassName;

Les espaces de noms peuvent également avoir du sens dans le contexte de GraphQL, pour éviter les conflits potentiels suivants qui se produisent dans le schéma :

Avoir deux types avec le même nom
Avoir deux champs sur le même type avec le même nom
Avoir deux directives avec le même nom

Les espaces de noms ont été demandés pour la spécification 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.

Cependant, Lee Byron (l'un des créateurs de GraphQL alors qu'il travaillait chez Facebook) estime que l'ajout d'espaces de noms à la spécification n'est pas justifié. Dans ce commentaire, il explique comment Facebook gère les milliers de types dans son schéma GraphQL sans conflit :

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. [...]

Mais le fait que cette stratégie fonctionne pour Facebook ne signifie pas qu'elle fonctionnera dans WordPress : comme Facebook contrôle toutes les entrées de son schéma GraphQL, il peut se permettre de suivre une procédure pour nommer les entités, en s'assurant qu'aucun conflit ne surgit. Mais un site WordPress dépend fortement d'extensions tierces, et ne contrôle pas comment ces extensions sont produites.

Par exemple, si un site utilise les extensions WooCommerce et Easy Digital Downloads, et qu'elles ont toutes deux un type nommé Product pour le schéma GraphQL, il y aura un conflit. Le seul recours pour le propriétaire du site est de contacter l'une des entreprises et de lui demander de modifier son code. Ce n'est pas de la prévention, mais de la correction, et c'est peu fiable.

Les espaces de noms peuvent alors donner aux propriétaires de sites WordPress la tranquillité d'esprit que leur code fonctionnera toujours. Si deux types portent le nom Product, l'administrateur du site peut activer les espaces de noms dans le schéma GraphQL, et ces types seront automatiquement renommés en WooCommerce_Product et EDD_Product, évitant ainsi le conflit.

Comme avantage supplémentaire, les espaces de noms rendent le schéma GraphQL plus élégant : si WooCommerce voulait s'assurer qu'aucun conflit ne surgira jamais avec son extension, alors il devrait « namespacer » ses types dans le nom du type lui-même : WCProduct, WCDownload et WCPayment (ou, pour être absolument certain que cela fonctionnera toujours, il pourrait les appeler WooCommerceProduct, WooCommerceDownload et WooCommercePayment). Grâce aux espaces de noms, ces types peuvent avoir les noms plus naturels Product, Download et Payment.