ฟีเจอร์ที่กำหนดเองสำหรับ Schema

ฟีเจอร์หลายอย่างที่เสนอสำหรับข้อกำหนด GraphQL ได้รับการพัฒนาใน Gato GraphQL แล้ว จึงไม่ต้องรอให้มาตรฐานรองรับก่อน

​

การทำ Namespace ให้กับ Schema

หากปลั๊กอิน WooCommerce และ Easy Digital Downloads ต่างก็พัฒนาประเภท Product สำหรับ GraphQL API ก็จะไม่สามารถติดตั้งทั้งสองปลั๊กอินพร้อมกันได้ เนื่องจากประเภทของทั้งสองจะขัดแย้งกัน

การทำ Namespace ให้กับ Schema ช่วยหลีกเลี่ยงความขัดแย้งใน Schema โดยการเพิ่ม Namespace ให้กับชื่อประเภททั้งหมด ดังนั้นประเภท Product จะกลายเป็น Woo_Product และ EDD_Product ตามลำดับ และประเภทเหล่านี้สามารถเพิ่มใน Schema เดียวกันได้

รูปภาพนี้แสดง Schema ที่มี Namespace โดยประเภท Event และ Location ได้รับคำนำหน้า EM_ เพื่อป้องกันการชนกันของชื่อ:

​

Global Fields

Global Fields คือฟิลด์ที่สามารถเข้าถึงได้จากทุกประเภทใน GraphQL Schema (โดยกำหนดไว้เพียงครั้งเดียว)

GraphQL Schema เปิดเผยประเภทต่างๆ เช่น Post, User และ Comment รวมถึงฟิลด์ที่ใช้ได้สำหรับแต่ละประเภท เช่น Post.title, User.name และ Comment.responses ฟิลด์เหล่านี้เกี่ยวข้องกับ "ข้อมูล" เนื่องจากดึงข้อมูลเฉพาะจาก Entity

Gato GraphQL นอกจากนี้ยังเสนอฟิลด์อีกประเภทหนึ่ง: ฟิลด์ที่ให้ "ฟังก์ชันการทำงาน" แทนที่จะเป็นข้อมูล

ตัวอย่าง Global Fields ได้แก่:

• _not
• _if
• _equals
• _isEmpty
• _echo
• _sprintf
• _arrayItem
• _arrayAddItem
• _arrayUnique
• และอีกมากมาย

ฟิลด์ฟังก์ชันการทำงานมีประโยชน์สำหรับการดึงข้อมูลที่จัดเก็บไว้นอก WordPress และสำหรับการจัดการข้อมูลหลังจากดึงมาแล้ว ช่วยให้เราสามารถแปลงค่าของฟิลด์ตามที่ต้องการ และมอบความสามารถในการนำเข้า/ส่งออกข้อมูลที่มีประสิทธิภาพ

ฟิลด์ฟังก์ชันการทำงานไม่ได้เป็นของประเภทเฉพาะ เช่น Post หรือ User แต่เป็นของทุกประเภทใน Schema นั่นคือเหตุผลที่ฟิลด์เหล่านี้ได้รับการจัดการในรูปแบบพิเศษใน Gato GraphQL ภายใต้ชื่อ "Global Fields"

​

Field to Input

ดึงค่าของฟิลด์ จัดการมัน และส่งเป็น Input ไปยังฟิลด์อื่น ทั้งหมดภายใน queries เดียวกัน

query {
  posts {
    excerpt
 
    # Referencing previous field with name "excerpt"
    isEmptyExcerpt: _isEmpty(value: $__excerpt)
 
    # Referencing previous field with alias "isEmptyExcerpt"
    isNotEmptyExcerpt: _not(value: $__isEmptyExcerpt)
  }
}Copy

​

Composable Directives

บ่อยครั้งที่ Directive ไม่สามารถนำไปใช้กับฟิลด์ได้ เนื่องจาก Input ของมันแตกต่างจาก Output ของฟิลด์ ตัวอย่างเช่น Directive @strUpperCase รับ String เป็น Input จึงไม่สามารถนำไปใช้กับฟิลด์ User.capabilities ที่คืนค่าเป็น Array ของ String ได้

ด้วย Composable Directives Directive สามารถเสริม Directive อื่นเพื่อปรับเปลี่ยนพฤติกรรมหรือเติมเต็มช่องว่าง ซึ่งช่วยขจัดความจำเป็นในการทำซ้ำฟิลด์หรือ Directive เพียงเพื่อเปลี่ยน Input หรือประเภทการคืนค่า ป้องกันความซับซ้อนที่ไม่จำเป็น

ใน queries นี้ Directive @underEachArrayItem วนซ้ำผ่าน Array ของ String และนำ Directive ที่ซ้อนอยู่ @strUpperCase ไปใช้กับแต่ละรายการ เพื่อแก้ไขความไม่ตรงกันของประเภท:

query {
  users {
    capabilities
      @underEachArrayItem
        @strUpperCase
  }
}Copy

​

Multi-field Directives

ให้ Directives นำไปใช้กับหลายฟิลด์พร้อมกัน (แทนที่จะเป็นเพียงฟิลด์เดียว) เพื่อประสิทธิภาพและกรณีการใช้งานที่ขยายออกไป

เมื่อเปิดใช้งาน อาร์กิวเมนต์ affectAdditionalFieldsUnderPos จะถูกเพิ่มให้กับ Directives ทั้งหมด ซึ่งสามารถระบุตำแหน่งสัมพัทธ์ของฟิลด์เพิ่มเติมที่จะนำ Directive ไปใช้ได้

ตัวอย่างเช่น ใน queries ต่อไปนี้ Directive @strTranslate จะถูกนำไปใช้กับฟิลด์ content เท่านั้น:

query {
  posts {
    excerpt
    content @strTranslate
  }
}Copy

ฟิลด์ excerpt สามารถนำ Directive @strTranslate ไปใช้ได้เช่นกัน โดยการเพิ่มอาร์กิวเมนต์ Directive affectAdditionalFieldsUnderPos ด้วยค่า [1] (เนื่องจาก 1 คือตำแหน่งสัมพัทธ์ของฟิลด์ excerpt จาก Directive @strTranslate):

query {
  posts {
    excerpt
    content
      @strTranslate(
        affectAdditionalFieldsUnderPos: [1]
      )
  }
}Copy

​

การกำหนดเวอร์ชันสำหรับฟิลด์และ Directive

กำหนดเวอร์ชันให้กับฟิลด์และ Directive อย่างอิสระจาก Schema

แทนที่จะพัฒนา Schema ทั้งหมด (ซึ่งต้องเปลี่ยนชื่อฟิลด์หรือ Directive ที่ถูกแก้ไข) เราสามารถ:

• เก็บการพัฒนาที่แตกต่างกันไว้ภายใต้ชื่อฟิลด์หรือ Directive เดียวกัน
• เปิดเผยการพัฒนาเดิมภายใต้แท็ก โดยใช้ Semantic Versioning
• เข้าถึงเวอร์ชันเฉพาะผ่านอาร์กิวเมนต์ฟิลด์/Directive versionConstraint

​

Proactive Feedback

ใช้รายการระดับบนสุด extensions เพื่อส่งข้อมูลเกี่ยวกับการ Deprecation และคำเตือนในการตอบสนองต่อ queries

• Deprecations: Deprecation จะถูกส่งคืนใน queries เดียวกับที่มีฟิลด์ที่ Deprecated ไม่ใช่แค่เมื่อทำ Introspection เท่านั้น
• Warnings: คำเตือนคือปัญหาที่ถือว่าไม่ขัดขวางการทำงาน กล่าวคือ ช่วยปรับปรุง queries แต่ไม่ทำให้เสียหาย

ตัวอย่างเช่น queries ต่อไปนี้ส่งออกสองฟิลด์โดยใช้ชื่อตัวแปรไดนามิก "prop" เดียวกัน ซึ่งสร้างคำเตือน:

query {
  posts {
    excerpt @export(as: "prop")
    content @export(as: "prop")
  }
}Copy

การตอบสนองจะรวมส่วน warnings (ภายใต้ extensions) พร้อมข้อความที่สอดคล้องกัน:

{
  "extensions": {
    "warnings": [
      {
        "message": "Dynamic variable with name 'props' had already been set, had its value overridden",
        "locations": [
          {
            "line": 4,
            "column": 25
          }
        ]
      }
    ]
  },
  "data": {
    "posts": {
      "excerpt": "Hello world!",
      "Content": "<p>Hello world!</p>"
    }
  }
}Copy