Namespace skema untuk menghindari konflik
Developer yang menerbitkan plugin di direktori WordPress tidak tahu terlebih dahulu siapa yang akan menggunakan plugin mereka, atau konfigurasi/lingkungan apa yang akan dimiliki situs tersebut, termasuk plugin lain apa saja yang mungkin terpasang. Akibatnya, plugin harus siap menghadapi konflik, dan berupaya mencegahnya sejak awal.
Salah satu cara plugin WordPress menghindari konflik adalah melalui namespace PHP. Namespace digunakan secara luas dalam komunitas PHP, mengikuti PHP Standard Recommendation PSR-4 untuk mengaktifkan Composer autoloading. Paket PHP harus menyertakan nama vendor, seperti "vendor-name/package-name", dan namespace yang sesuai hadir pada kode PHP:
<?php
namespace VendorName\PackageName\ClassName;Namespace juga dapat masuk akal dalam konteks GraphQL, untuk menghindari potensi konflik berikut yang terjadi pada skema:
- Memiliki dua tipe dengan nama yang sama
- Memiliki dua field pada tipe yang sama dengan nama yang sama
- Memiliki dua direktif dengan nama yang sama
Namespace telah diminta untuk spesifikasi 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.
Namun, Lee Byron (salah satu pencipta GraphQL saat bekerja di Facebook) percaya bahwa menambahkan namespace ke spesifikasi tidak diperlukan. Dalam komentar ini, ia menjelaskan bagaimana Facebook mengelola ribuan tipe dalam skema GraphQL-nya tanpa konflik:
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. [...]
Namun fakta bahwa strategi ini berhasil untuk Facebook tidak berarti akan berhasil di WordPress: karena Facebook mengontrol semua masukan ke skema GraphQL-nya, ia dapat menerapkan prosedur penamaan entitas sehingga tidak ada konflik yang muncul. Tetapi situs WordPress sangat bergantung pada plugin pihak ketiga, dan tidak mengontrol bagaimana plugin-plugin tersebut dibuat.
Misalnya, jika sebuah situs menggunakan plugin WooCommerce dan Easy Digital Downloads, dan keduanya memiliki tipe bernama Product untuk skema GraphQL, maka akan terjadi konflik. Satu-satunya cara bagi pemilik situs adalah menghubungi salah satu perusahaan dan meminta mereka mengubah kode mereka. Ini bukan pencegahan, melainkan koreksi, dan tidak dapat diandalkan.
Namespace kemudian dapat memberikan ketenangan pikiran bagi pemilik situs WordPress bahwa kode mereka akan selalu berfungsi. Jika dua tipe memiliki nama Product, admin situs dapat mengaktifkan namespace dalam skema GraphQL, dan tipe-tipe ini akan secara otomatis diganti namanya menjadi WooCommerce_Product dan EDD_Product, menghindari konflik.
Sebagai manfaat tambahan, namespace membuat skema GraphQL lebih elegan: jika WooCommerce ingin memastikan tidak pernah ada konflik dengan plugin-nya, maka ia harus "menamai dengan namespace" tipe-tipenya pada nama tipe itu sendiri: WCProduct, WCDownload dan WCPayment (atau, untuk benar-benar yakin akan selalu berfungsi, mungkin menamai mereka WooCommerceProduct, WooCommerceDownload dan WooCommercePayment). Berkat namespace, tipe-tipe ini dapat memiliki nama yang lebih alami: Product, Download dan Payment.