https://px-wing.hatenablog.com/entry/2020/08/25/084518

はじめに

GraphQLの調査するにあたり、フラグメントを再度確認する。
前回はざっくりしか触れなかったので。 px-wing.hatenablog.com px-wing.hatenablog.com

フラグメント

フラグメントは基本的に、再利用可能なクエリの一部です。
各クエリのフィールドが複数回繰り返されているため、まだ改善の余地があります。それらは同じ選択セットであるため、フィールドを一度だけ定義して、必要に応じて参照することができます。そのためにフラグメントを使用できます。

フラグメントを利用する前

query getUsers {
    admins: users(role: ADMIN) {
        id
        firstName
        lastName
        phone
        username
    }
    accountants: users(role: ACCOUNTANT) {
        id
        firstName
        lastName
        phone
        username
    }
}

フラグメント使用後

結果は同じですが、リファクタリングとコードの再利用の観点から、この方法でクエリを記述することには多くの利点があります。

query getUsers {
    admins: users(role: admin) {
        ...userFields
    }
    staffs: users(role: accountant) {
        ...userFields
    }
}
fragment userFields on User {
    id
    firstName
    lastName
    mailAddress
}

インラインフラグメント

インラインフラグメントは、実行時に型を解決する必要があるクエリに役立ちます。また、GraphQLの抽象型（UnionまたはInterface）の 1つを実装する必要がある場合は、インラインフラグメントを使用します。インターフェイスのモジュールで説明したように、インターフェイスの最も一般的な例はノードインターフェイスです。Unionは通常、GraphQLでの検索の実装に使用されます。これらのタイプを照会するときは、インラインフラグメントを使用して条件付きで実行する必要があります。この検索クエリは、このインラインフラグメントがどのように見えるかを示しています。
githubを利用したquery

query searchwithTypeName {
  search(query: "PHP", type: USER, first: 3) {
    nodes {
      __typename
      ... on User {
        id
        name
        url
      }
      ... on Organization {
        id
        name
        projectsUrl
      }
    }
  }
}

下記のクエリの場合、ユーザーおよび会社に関するステートメントは、タイプ条件です。タイプ条件を使用すると、ユーザーと会社の両方のタイプのフィールドが異なっていても、スキーマ内の異なるタイプに各フラグメントを適用できます。

query searchQuery {
    search(query: "Atheros") {
        ... on User {
        email
        firstName
        lastName
    }
    ... on Company {
        name
        vatId
        }
    }
}

まとめ

RelayやApolloなどのフロントエンドキャッシングクライアントでも頻繁に使用される。リレーには、いわゆるフラグメントコンテナーがあり、コンポーネントのコンポーネントのデータ要件を定義する。アポロクライアントでは、クエリコロケーションにフラグメントの概念を使用する。これらのキャッシングクライアントのフラグメントは、UIコンポーネントのデータニーズに基本的に完全に一致している。これは、FlowまたはTypeScriptを使用した静的型付けに有利に使用できる