本文へスキップ

Relay v15.0

·読了時間4分

Relayチームは、Relay v15のリリースを発表できることを嬉しく思っています。このリリースはメジャーバージョンアップであり、いくつかの破壊的変更が含まれていますが、ほとんどのユーザーは影響を受けず、シームレスなアップグレードが可能になると予想しています。変更の完全なリストは、v15リリースノートをご覧ください。

Relay 15の新機能​

インターフェースでの@refetchableのサポート​

以前は、サーバーインターフェース型上のフラグメント定義に@refetchableディレクティブを追加することができませんでした。

// schema.graphql

interface RefetchableInterfaceFoo @fetchable(field_name: "id") {
    id: ID!
}

extend type Query {
  fetch__RefetchableInterfaceFoo(id: ID!): RefetchableInterfaceFoo
}

// fragment

fragment RefetchableFragmentFoo on RefetchableInterfaceFoo
  @refetchable(queryName: "RefetchableFragmentFooQuery") {
  id
}

永続化クエリ改善​

URLベースの永続化クエリを使用する場合、クエリを永続化するリクエストに送信するカスタムヘッダーを指定できるようになりました。たとえば、これを使用して、クエリ永続化URLエンドポイントに認証ヘッダーを送信できます。

persistConfig: {
  url: 'example.com/persist',
  headers: {
    Authorization: 'bearer TOKEN'
  }
}

ファイルベースの永続化クエリの場合、永続化クエリテキストからすべての空白を削除する新しい機能フラグcompact_query_textを追加しました。これにより、ファイルサイズを60％以上削減できます。この新しい機能フラグは、Relayの設定ファイルで有効にできます。

persistConfig: {
  file: 'path/to/file.json',
  algorithm: 'SHA256'
},
featureFlags: {
  compact_query_text: true
}

型安全なアップデートが欠落しているフィールドハンドラーをサポート​

型安全なアップデータは、欠落しているフィールドハンドラーをサポートするようになりました。以前は、型安全なアップデータでnode(id: 4) { ... on User { name, __typename } }を選択した場合、そのユーザーが別の方法（例：best_friend { name }）でフェッチされていた場合、型安全なアップデータを使用してそのユーザーにアクセスして変更することはできませんでした。

このリリースでは、型安全なアップデータで欠落しているフィールドハンドラーのサポートを追加しました。つまり、ノードに欠落しているフィールドハンドラーが設定されている場合（この例のように）、この欠落しているフィールドハンドラーを使用してユーザーの名前を更新できます。

これをサポートするために、欠落しているフィールドハンドラーのシグネチャが変更されました。ハンドラーで使用されるrecord引数は、以前はRecord型（型指定されていないデータの寄せ集め）を受け取っていましたが、現在はReadOnlyRecordProxyを受け取ります。さらに、NormalizationLinkedField型のfield引数は、ReaderLinkedFieldとNormalizationLinkedFieldの両方に含まれるプロパティを含むCommonLinkedFieldになりました。

Flow型の改善​

Flowユーザーは、より多くのRelay APIでgraphqlリテラルから推論された型を取得するようになりました。Flowユーザーは、usePreloadedQuery、useQueryLoader、useRefetchableFragment、usePaginationFragment、useBlockingPaginationFragment APIメソッドの戻り値を明示的に型指定する必要がなくなりました。

Relay Resolverの改善​

前回のリリース以降の開発努力のかなりの部分を、Relay Resolvers（グラフに派生データを提供するメカニズム）の改善に費やしました。Relay Resolversはまだ実験段階であり、APIが将来変更される可能性があることに注意してください。

より簡潔なdocblockタグ​

Relay Resolver関数の注釈が簡素化されました。多くのシナリオでは、ParentType.field_name: ReturnType構文を使用して、Relay Resolverが公開する新しいフィールドを定義できるようになりました。

変更前

/**
 * @RelayResolver
 * @onType User
 * @fieldName favorite_page
 * @rootFragment myRootFragment
 */

変更後

/**
 * @RelayResolver User.favorite_page: Page
 * @rootFragment myRootFragment
 */

上記の例では、Page型はスキーマ型です。Relay Resolverがスキーマ型を返さない場合は、固定されたRelayResolverValue値を戻り値型として使用できます。

/**
 * @RelayResolver User.best_friend: RelayResolverValue
 * @rootFragment myRootFragment
 */

ファイルごとの複数のResolverの定義​

このリリース以前は、ファイルごとに1つのRelay Resolverしか許可されておらず、Relay Resolver関数をデフォルトエクスポートにする必要がありました。Relay 15では、ファイルごとに複数のRelay Resolverを定義し、名前付きエクスポートを使用できるようになりました。

/**
 * @RelayResolver User.favorite_page: Page
 * @rootFragment favoritePageFragment
 */
function usersFavoritePage(){
  ...
}

/**
 * @RelayResolver User.best_friend: RelayResolverValue
 * @rootFragment bestFriendFragment
 */
function usersBestFriend(){
  ...
}

module.exports = {
  usersFavoritePage,
  usersBestFriend
}

クエリを楽しんで！