การกำหนดค่า Schema
การกำหนดค่า Schemaการกำหนด Namespace ให้กับ Schema

การกำหนด Namespace ให้กับ Schema

ทำให้ Type และ Interface ทั้งหมดที่ Plugin เพิ่มเข้าไปใน Schema ได้รับการกำหนด Namespace โดยอัตโนมัติ

การกำหนด Namespace ให้กับ Schema ช่วยหลีกเลี่ยงความขัดแย้งของชื่อ ซึ่งเกิดขึ้นเมื่อเจ้าของต่างกัน (เช่น ทีมงานต่างกันในบริษัท หรือระหว่าง Plugin ของบุคคลที่สาม) ใช้ชื่อเดียวกันสำหรับ Type หรือ Interface

ตัวอย่างเช่น สมมติว่าบริษัท "AwesomeWP" มีทีม Tutorials และทีม Sales และทั้งสองทีมสร้าง Type Product สำหรับ GraphQL Schema ของบริษัท ทำให้เกิดความขัดแย้ง

เมื่อกำหนด Namespace ให้กับ Schema ทั้งสอง Type จะถูกแปลงโดยอัตโนมัติเป็น AwesomeWPTutorialsProduct และ AwesomeWPSalesProduct ซึ่งหลีกเลี่ยงความขัดแย้งโดยไม่ต้องแก้ไข Schema ด้วยตนเอง หรือต้องให้ทีมงานติดต่อประสานงานกัน

Entity จาก WordPress Data Model ไม่มีการกำหนด Namespace

WordPress Data Model ถือเป็นมาตรฐาน และ Type ของ GraphQL Schema (เช่น Post และ User) รวมถึง Interface (เช่น Commentable และ WithMeta) จะไม่มีการกำหนด Namespace

การกำหนด Namespace ให้กับ Schema ใน Endpoint

มี 2 ระดับที่สามารถกำหนดได้ว่า Schema จะมีการกำหนด Namespace หรือไม่ เรียงตามลำดับความสำคัญ:

1. บน Schema Configuration

การกำหนด Namespace ให้กับ Schema สำหรับ Custom Endpoint หรือ Persisted Query สามารถกำหนดได้ผ่าน Schema Configuration ที่เกี่ยวข้อง:

Namespacing, set in the Schema configuration

2. โหมดเริ่มต้น กำหนดใน Settings

หาก Schema Configuration มีค่า "Default" ระบบจะใช้โหมดที่กำหนดใน Settings:

Namespacing in Settings
Namespacing in Settings

การแสดงภาพ Schema ที่มี Namespace

ใช้ Voyager client เพื่อแสดงภาพ Schema ที่มีการกำหนด Namespace

เมื่อปิดใช้งาน Namespace WordPress Schema จะแสดงดังนี้:

Interactive schema

เมื่อเปิดใช้งาน Type และ Interface ที่ Plugin เพิ่มเข้ามาจะมีการกำหนด Namespace และแสดงดังนี้:

Namespaced interactive schema

การ Queries ชื่อ Type ที่มี (หรือไม่มี) Namespace

เมื่อเปิดใช้งาน Namespace แล้ว Type สามารถ Queries ได้โดยใช้ทั้งชื่อ Type ที่มี Namespace และไม่มี Namespace ดังนั้นจึงต้องแก้ไขเฉพาะ Queries ที่เกี่ยวข้องกับ Type ที่ขัดแย้งกันเท่านั้น ไม่ใช่ทั้งหมด

ตัวอย่างเช่น หากทีม Sales ของ AwesomeWP มี Type Discount ด้วย Queries ที่ขอชื่อ Type นี้ยังคงทำงานได้:

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

เฉพาะ Type ที่ขัดแย้งกันอย่าง Product เท่านั้นที่ต้องอัปเดตเป็น AwesomeWPSalesProduct ใน Queries เพื่อลบความคลุมเครือ:

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

GraphQL Spec

ฟังก์ชันนี้ยังไม่ได้เป็นส่วนหนึ่งของ GraphQL Spec แต่มีการร้องขอใน: