Logo
Concepten, Ideeën, Strategieën
Concepten, Ideeën, StrategieënNamespacing van het schema om conflicten te vermijden

Namespacing van het schema om conflicten te vermijden

Ontwikkelaars die plugins publiceren in de WordPress-directory weten van tevoren niet wie hun plugins zal gebruiken, of welke configuratie/omgeving de site zal hebben, inclusief welke andere plugins er mogelijk geïnstalleerd zijn. Daarom moet de plugin voorbereid zijn op conflicten en proberen deze vooraf te voorkomen.

Een van de manieren waarop WordPress-plugins conflicten vermijden, is via PHP-namespacing. Namespaces worden veel gebruikt binnen de PHP-gemeenschap, in navolging van de PHP Standard Recommendation PSR-4 om Composer autoloading mogelijk te maken. PHP-packages moeten de naam van de leverancier bevatten, als "vendor-name/package-name", en de bijbehorende namespace is aanwezig in de PHP-code:

<?php
namespace VendorName\PackageName\ClassName;

Namespacing kan ook zinvol zijn binnen de context van GraphQL, om de volgende potentiële conflicten in het schema te vermijden:

  • Twee typen met dezelfde naam hebben
  • Twee velden van hetzelfde type met dezelfde naam hebben
  • Twee directives met dezelfde naam hebben

Namespacing is aangevraagd voor de GraphQL-spec:

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.

Lee Byron (een van de bedenkers van GraphQL tijdens zijn werk bij Facebook) vindt echter dat het toevoegen van namespacing aan de spec niet gerechtvaardigd is. In dit commentaar legt hij uit hoe Facebook duizenden typen in zijn GraphQL-schema beheert zonder conflicten:

We avoid naming collisions in two ways:

  1. integration tests.

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

  1. Common naming patterns.

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

Maar het feit dat deze strategie werkt voor Facebook, betekent niet dat het ook werkt in WordPress: omdat Facebook alle invoer voor zijn GraphQL-schema controleert, kan het zich veroorloven een procedure te volgen voor het benoemen van entiteiten, zodat er geen conflict ontstaat. Een WordPress-site is echter sterk afhankelijk van plugins van derden, en heeft geen controle over hoe deze plugins worden gemaakt.

Als een site bijvoorbeeld gebruikmaakt van de plugins WooCommerce en Easy Digital Downloads, en beide een type genaamd Product hebben voor het GraphQL-schema, ontstaat er een conflict. Het enige wat de site-eigenaar kan doen, is contact opnemen met een van de bedrijven en vragen om hun code aan te passen. Dit is geen preventie, maar correctie, en dat is onbetrouwbaar.

Namespacing kan WordPress-site-eigenaren dan de gemoedsrust geven dat hun code altijd blijft werken. Als twee typen de naam Product hebben, kan de beheerder van de site namespacing inschakelen in het GraphQL-schema, waarna deze typen automatisch worden hernoemd naar WooCommerce_Product en EDD_Product, waardoor het conflict wordt vermeden.

Als bijkomend voordeel maakt namespacing het GraphQL-schema eleganter: als WooCommerce er zeker van wilde zijn dat er nooit een conflict met zijn plugin zou ontstaan, moest het zijn typen "namespacen" in de typenaam zelf: WCProduct, WCDownload en WCPayment (of, om volledig zeker te zijn, zou het ze WooCommerceProduct, WooCommerceDownload en WooCommercePayment kunnen noemen). Dankzij namespacing kunnen deze typen de meer natuurlijke namen Product, Download en Payment dragen.