指令是GraphQL最好，也是最不言而喻的功能之一。
讓我們探索使用GraphQL的內置架構和操作指令，所有符合GraphQL規格API都必須實現。如果您使用動態前端，它們非常有用，因為您可以根據用戶與用戶交互的方式進行控制來減少響應有效載荷。
讓我們想像一個應用程序，您可以選擇自定義表中顯示的列。如果隱藏兩個或三列，那麼實際上無需為這些單元格獲取數據。但是，使用GraphQL指令，我們可以選擇包括或跳過這些字段。
GraphQL規範定義了什麼是指令以及可以使用的位置。具體而言，指令可以由消費者操作（例如查詢）以及基礎架構本身使用。或者，簡單地說，指令要么基於模式或操作。生成架構時使用架構指令，並且執行查詢時運行指令運行。
簡而言之，指令可用於元數據，運行時提示，運行時解析（例如以特定格式返回日期）和擴展描述（如棄用）。
GraphQL擁有規範工作草案中定義的四個主要指令，其中一個未發行為工作草案。
如果您密切關注GraphQL，您還會注意到，您可以在今天可以嘗試的JavaScript實現合併了兩個其他指令 - @Stream和@defer。當社區在現實世界應用中對其進行測試時，這些都不是官方規格的一部分。
@Include指令符合其名稱，允許我們通過傳遞IF參數來有條件地包括字段。由於有條件的條件，因此在查詢中使用變量檢查真實性是有意義的。
例如，如果以下示例中的變量是真實的，則名稱字段將包含在查詢響應中。
查詢getusers（$ dishame：boolean）{
用戶{
ID
名稱@Include（如果：$ dispayame）
}
}相反，我們可以選擇不將變量$與查詢一起傳遞為false的變量$通過將字段包含在內。我們還可以指定$ showeame變量的默認值，因此無需在每個請求中傳遞它：
查詢getusers（$ dishame：boolean = true）{
用戶{
ID
名稱@Include（如果：$ dispayame）
}
}我們可以用僅此功能來表達同樣的事情，但是使用@SKIP指令。如果價值是真實的，那麼它將像您期望的那樣跳過該領域。
查詢getusers（$ hidename：boolean）{
用戶{
ID
名稱@skip（如果：$ hidename）
}
}儘管這適用於單個字段，但有時我們可能希望包括或跳過多個字段。我們可以在這樣的多行中復制@include和@skip的用法：
查詢getusers（$ include fields：boolean）{
用戶{
ID
名稱@include（如果：$ include fields）
電子郵件@include（如果：$ include fields）
角色@include（如果：$ include fields）
}
}@skip和@include指令均可在字段，片段蔓延和內聯片段上使用，這意味著我們可以做其他事情，例如使用Inline Fragments：
查詢getusers（$ dubludefields：boolean）{
用戶{
ID
...在用戶@skip上（如果：$ dubludefields）{
姓名
電子郵件
角色
}
}
}如果已經定義了片段，當我們將片段擴展到查詢中時，我們也可以使用@skip和@include：
用戶上的fragment用戶{
姓名
電子郵件
角色
}
查詢getusers（$ dubludefields：boolean）{
用戶{
ID
...用戶@skip（如果：$ dubludefields）
}
}@deprectated指令僅出現在模式中，並且不是用戶所提供的作為我們上面看到的查詢的一部分。相反，@deprected指令是由維護GraphQL API架構的開發人員指定的。
作為用戶，如果我們嘗試獲取架構中已棄用的字段，我們將收到這樣的警告，提供上下文幫助。
為了標記不推翻的字段，我們需要在架構定義語言（SDL）中使用@Deprectated指令，並在此類參數中傳遞原因：
鍵入用戶{
id：id！
標題：字符串@DepRecated（原因：“使用名稱代替”）
名稱：字符串！
電子郵件：字符串！
角色：角色
}如果我們將其與@include指令配對，則可以根據查詢變量有條件地獲取不棄用的字段：
用戶上的fragment用戶{
標題@include（如果：$ incresseprecatedFields）
姓名
電子郵件
角色
}
查詢getusers（$ inccesseprecatedFields：boolean！= false）{
用戶{
ID
...用戶
}
}@specifiedby是指令的第四個，目前是工作草案的一部分。它設置為自定義標量實現，並採用一個URL參數，該參數應指向標量的規範。
例如，如果我們為電子郵件地址添加自定義標量，我們將希望將URL傳遞給我們用作的正則條件的規範。使用最後一個示例和RFC＃822中定義的建議，將在架構中定義了emailaddress的標量：
標量emailaddress @specifiedby（url：“ https：//www.w3.org/protocols/rfc822/”）
建議定制指令具有前綴的名稱，以防止與其他附加指令發生碰撞。如果您正在尋找一個示例自定義指令，以及它的創建方式，請查看GraphQl公共模式。這是一個自定義的GraphQL指令，具有代碼和模式優先的支持，用於註釋哪些API可以在公共場合消費。
因此，這是GraphQL指令的高級外觀。同樣，我相信指示是一種被其他GraphQL功能所掩蓋的無名英雄。我們已經對GraphQL模式有了很大的控制，指令為我們提供了更細粒度的控制，以便從查詢中獲得我們想要的東西。這就是這種效率，這使GraphQl API如此快速，最終更友好地使用。
而且，如果您要構建GraphQl API，請確保將這些指令包括在內省查詢中。.擁有它們不僅使開發人員獲得額外控制的好處，而且可以使總體更好的開發人員體驗。試想一下，正確地@deprecate字段將有多大幫助，以便開發人員知道該怎麼做，而不需要離開代碼？這本身就是強大的。
標題圖形由IsabelGonçalves在Unsplash上提供
以上是使用內置的GraphQL指令的詳細內容。更多資訊請關注PHP中文網其他相關文章！
