Pemberian Namespace pada Skema

Buat semua tipe dan antarmuka yang ditambahkan ke skema oleh plugin secara otomatis mendapatkan namespace.

Pemberian namespace pada skema menghindari konflik penamaan, yang terjadi ketika pemilik berbeda (mis.: tim yang berbeda di perusahaan, atau di antara plugin pihak ketiga) menggunakan nama yang sama untuk suatu tipe atau antarmuka.

Misalnya, katakanlah perusahaan "AwesomeWP" memiliki tim Tutorials dan tim Sales, dan keduanya membuat tipe Product untuk skema GraphQL perusahaan, sehingga menimbulkan konflik.

Dengan pemberian namespace pada skema, kedua tipe tersebut akan secara otomatis diubah menjadi AwesomeWPTutorialsProduct dan AwesomeWPSalesProduct, menghindari konflik tanpa harus memodifikasi skema secara manual, atau meminta kedua tim berinteraksi satu sama lain.

​

Entitas dari model data WordPress tidak diberi namespace

Model data WordPress dianggap kanonik, dan tipe skema GraphQL-nya (seperti Post dan User) serta antarmuka (seperti Commentable dan WithMeta) tidak diberi namespace.

​

Pemberian namespace pada skema di endpoint

Ada 2 tingkat di mana kita dapat menentukan apakah skema akan diberi namespace atau tidak. Berdasarkan urutan prioritas:

​

1. Pada konfigurasi skema

Pemberian namespace pada skema untuk custom endpoint atau persisted query dapat ditentukan melalui konfigurasi skema yang sesuai:

​

2. Mode default, ditentukan di Pengaturan

Jika konfigurasi skema memiliki nilai "Default", maka akan menggunakan mode yang ditentukan di Pengaturan:

​

Memvisualisasikan skema dengan namespace

Gunakan klien Voyager untuk memvisualisasikan skema dengan namespace.

Ketika namespace dinonaktifkan, skema WordPress terlihat seperti ini:

Ketika diaktifkan, tipe dan antarmuka yang ditambahkan oleh plugin diberi namespace, terlihat seperti ini:

​

Query nama tipe (non-)namespaced

Setelah namespace diaktifkan, tipe dapat di-query menggunakan nama tipe dengan namespace maupun tanpa namespace. Oleh karena itu, hanya query yang melibatkan tipe yang berkonflik yang perlu diedit, bukan semuanya.

Misalnya, jika tim Sales AwesomeWP juga memiliki tipe Discount, sebuah query yang meminta nama tipe ini tetap berfungsi:

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

Hanya tipe yang berkonflik Product yang harus diperbarui menjadi AwesomeWPSalesProduct dalam query, agar tidak ada ambiguitas:

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

​

Spesifikasi GraphQL

Fungsionalitas ini saat ini bukan bagian dari spesifikasi GraphQL, tetapi telah diminta dalam:

• Issue #163 - Namespaces.