iT邦幫忙

2017 iT 邦幫忙鐵人賽
DAY 22
0

前言

這篇是「GraphQL 入門」這個小系列的最後一篇,要來提到 GraphQL 一個非常重要的功能 - Fragment。它可以讓各模組自己定義各自的資料需求,並拼裝合成一個 Query 統一發送到伺服器,是以 GraphQL 為主的前端架構的關鍵。

使用 Fragment

還記得前幾篇所做過的 Query 嗎?

{
  users {
    id
    name
  }
}

其實還可以把欄位定義在 fragment,然後再放進 Query 中:

{
  users {
    ...userInfo
  }
}

fragment userInfo on User {
  id
  name
}

如下圖,會得到一模一樣的回傳值:

不過用 Fragment 到底有什麼好處呢?

第一,可以直接在對應的 Type 上重複查詢這組屬性:

{
  users {
    ...userInfo
    posts {
      id
      title
      author {
        ...userInfo
      }
    }
  }
}

fragment userInfo on User {
  id
  name
}

除了能避免重複寫一樣的屬性,以下要提到的另一個用法才是關鍵重點:拼裝 Query。

拼裝 Query

在我們以往的開發經驗中可以得知,UI Component 的模組化跟 API 呼叫通常是彼此獨立的。雖然只有個別的 UI Component 知道自己需要什麼樣的資料來顯示畫面,但如果讓每個 Component 自行呼叫 API,不只是會發出很多的網路請求拖累效能,還會有很多資料重疊的部分被浪費掉。

假設 Component1Component2Component3 都有各自需要的資料,有可能重複有可能不重複。經過 Fragment 的拼裝後,不但能一次拿回來,而且資料欄位會剛好不多不少,是三個 Component 的資料聯集:

{
  users {
    ...userInfoRequiredByComponent1
    ...userInfoRequiredByComponent2
    ...userInfoRequiredByComponent3
  }
}

fragment userInfoRequiredByComponent1 on User {
  id
}

fragment userInfoRequiredByComponent2 on User {
  name
}

fragment userInfoRequiredByComponent3 on User {
  id
  name
}

上圖就如同我們說的一般,用一次的網路往返拿回足夠的資料。這就是包括 Relay 在內的許多 GraphQL 相關前端框架的核心概念。

結語

從這五篇的 GraphQL 文章應該已經可以大概知道它的核心語法與概念,更多的概念例如:Interface、Union、Alias、Directive 等等,想也不必在這邊提及,有興趣的話自然能找到更多的資源,而這系列畢竟是開發 App 的主題,讓我們從下一篇迅速回到正題吧。


上一篇
Day 21:GraphQL 入門 Part IV - Mutation
下一篇
Day 23:實作 OAuth 來使用 Github GraphQL API
系列文
使用 Modern Web 技術來打造 Native App30

尚未有邦友留言

立即登入留言