2016-01-22 55 views
3

https://facebook.github.io/relay/graphql/objectidentification.htm對於Node是什麼以及它如何表現非常清楚,但它沒有指定哪些對象必須實現它,或者如果對象沒有實現它會產生什麼後果。是否有一組功能不起作用?這些物體是否完全被忽略?並非現有規範中的所有對象(例如pageInfo)都實現它,因此它顯然不是普遍需要的,但pageInfo有些特殊情況。哪些中繼對象必須實現`Node`?

回答

2

關於Node接口的另一種思考方式是實現它的對象是refetchable。可重用性有效地意味着一個對象有一個ID可以用來識別對象並檢索它;按照慣例,這些ID通常是不透明的,但是將包含類型信息和該類型中的標識符(例如像「Account:1234」這樣的字符串的Base-64編碼)。

接力將在兩個方面發揮refetchability:

  • 在被稱爲「版本比較」,如果您已經有通過ID QWNjb3VudDoxMjM0標識的對象的一些數據的過程(比如,在nameaddress字段),然後導航到顯示其他字段(location,createdAt)的視圖,然後中繼可以創建一個「重新提交」該節點的最小查詢,但僅請求缺少的字段。
  • 與此相關,Relay將會區分連接並將利用接口填寫這些數據的缺失數據(例如:通過導航的某種組合,您可能在某個視圖中有一些項目的完整信息,但需要填寫location對於範圍內的某些項目,或者您可以通過突變修改連接中的項目)。因此,在基本分頁中,Relay通常會最終制作一個first + after查詢來擴展連接,但是如果您在真實應用程序中檢查其網絡流量,您還會看到它會對連接中的項目進行node查詢。

所以,是的,你說得對,pageInfo沒有實現Node,一下子就沒有真正意義它這樣做。

+0

也就是說:沒有*需要*來實現'Node',但是那些對象會被更有效地處理?我現在看到https://facebook.github.io/relay/graphql/connections.htm提到「如果此字段返回一個實現Node的對象,Relay可以執行某些優化,但是,這不是使用Relay的嚴格要求「。 – Evan

+0

正確。我不想過於強硬,但一個好的經驗法則可能是將其用於業務領域中的「核心」對象,尤其是那些可以通過頂級路線導航的對象,以及它們出現在連接中。最佳方法當然會因應用而異,但如果您可以便宜地實施'Node'(並且您經常可以),那麼至少在我上面提到的那些情況下,您可能會從中受益。 – wincent

相關問題