あなたのアプリケーションをリレーで考える方法

導入

第一印象

私はリレーについての良い第一印象を持っていないときにそれを使用し始めた.私はそれを理解するのは難しい、発見し、使用して、私はそれからの利点を見ていない.
たとえそれが好きでなかったとしても、私はチームの一員でした、そして、チームとして、我々はリレーに固執して、それが良い選択であるならば、長期的に見ます.
時間が経つにつれて、私はそれとうまくやって、それを使う方法を理解し始めました.私はまだ完全なアイデアを持っていなかったが、単にデータの取得のような単純な問題を解決するためにそれを使用する方法を実現するために、私が何をしていたかを知るためには、当時私にとって十分でした.

責任

数ヶ月後、私は技術リードに昇格し、それを理解し、なぜ私たちが使用しているものを使用している私のチームに説明する責任が来ました.チャレンジしました.なぜリレーを使うのか、何か他のものではないのかを理解する必要がありました.
そして、私は他の解決策のように、どのように、なぜあなたがそれを使用して知っていない場合は、あなたがそれを解決しようとしていると同じか、さらに悪い問題に直面するつもりです.

この記事

この記事は、我々がなぜリレーを使うのか理解するその過程の把握です.私はリレーを使用してアプリケーションを考える方法を示すつもりです、私はリレーが提供する他の解決策を理解するために、あなたが我々がたった今どんな問題を最初に理解する必要があると思っています.

リレーは何ですか。

これは、フロントエンドのデータを取得するプロセスを容易にしようとするJavaScriptフレームワークを使用してGraphQL . それはFacebookによって開発され、反応のコンポーネント化の同じイデアルで考案されました.

コンポーネントとリレーの反応

コンポーネントの背後にあるiDiiaは、コンポーネントと呼ばれる小さな部品に分割することにより、アプリケーションの複雑さを減らすことです.これらのコンポーネントを理解し、維持するために簡単であり、その規模をあなたのアプリケーションの能力を向上させます.

And how does that relates to Relay?

リレーの背後にあるIdeiaは、データ依存関係をコンポーネントと共に配置し、何らかの理由で有益であることです.

コンポーネントが動作するのに必要なデータを理解するのは簡単です.

お使いのコンポーネントがサーバーから他のデータを必要とする場合は、全体を変更する必要はありませんquery 構造、コンポーネントだけ.(すべてのケースはこのように動作しているわけではありません.

構造全体から分離したコンポーネントをテストするのは簡単です.

リレーの使い方

それを理解するには、下記のYouTubeページを見てみましょう.

サーバーからのデータを受け取る4つのコンポーネントに分割できます.

VideoPlayer : 我々が見ているビデオを与えるのに用いられます.おそらく必要videoSrc サーバから.

VideoDetails : タイトル、説明、著者、好きと嫌いの数のようなビデオの詳細を表示します.

RelatedVideos : YouTubeのアルゴリズムは、あなたが見たいと思っているビデオのリストです.

UserImg : ログインしたユーザープロファイルイメージをレンダリングします.

Just remembering that all of that it's just an example. For sure the real YouTube architecture it's much more complex than this.

これらのコンポーネントを念頭に置いて、リレーを使用してサーバからデータを取得する2つの方法があります.

1 .各コンポーネントは、必要なデータを取得する

その解決策を表すために、このようなダイアグラムを描くことができます.

左側には、YouTubeページの簡略化版があります.ここで、各コンポーネントは、灰色の円で表され、彼らはGraphQL クエリは以下のようになります.

graphql`
  query NavbarQuery {
    user {
      profileImg {
        src
      }
    }
  }
`

利益

この解を用いて,我々のアプリケーションの各部分に異なる負荷指標を示すことができた.このような

我々は画面に完全に彼のアクセスをブロックしていないと我々が取得しているデータを示し、我々がすでに取得したことによって、ユーザーエクスペリエンスを向上させることによって.

Here's an article explaining why you should use loading skeletons in your interface.

下方

最初の問題は、コンポーネントがレンダリングする別のものに依存するツリー構造に関連します.例として、ビデオを見せてくれるだけの構造を得ましょう.

ここでは、我々はデータを得るだけですvideoSrc コンポーネントVideoPlayer が完全にレンダリングされます.そして、何らかの理由で上記のこれらのコンポーネントのいずれかVideoPlayer 負荷に長い時間がかかる、我々はサーバーを呼び出すことができますし、ビデオの読み込みを開始するまで、その時間を待つ必要があります.
そのため、ビデオを2回読み込むことができます.

コンポーネントのレンダリングVideoPlayer .

領収書response からserver とvideoSrc データ.

もう1つの問題は、サーバーの多くの要求で終わるでしょう.そこでは、それらのそれぞれがデータのただ一つの部分だけを求めるでしょう.そして、一旦接続がサーバーで開かれるならば、我々は我々が必要とするすべてのデータを求めます.

Ok, so we have these two problems. What it's the alternative?

推奨事項

各コンポーネントのデータを取得するのではなく、一度ページロードで一度フェッチします.言い換えると、すべてのページがクエリです.

But didn't you said that Relay is built on colocating the data dependencies with the components that need them?

はい.私が言ったときdata dependencies 私はフェッチ機能を意味しませんでした、私はそれが必要であるデータの宣言を意味します.我々は、ページのレンダリングで一度だけ取得します.こんな感じでしょう

利益

これにより、ページロードにページを表示する必要があるすべてのデータを求めます.次のような利点があります.

サーバーに要求された量を減らします.

いくつかのコンポーネントがロードされるのを待ちませんので、ユーザに適切なデータを表示するためにロード時間を減らします.

データ依存性とフラグメントの共存

それの近くのコンポーネントのデータ依存性を割り当てるために、我々は使うことができますRelay Fragments .
エーFragment , インRelay , 特定のコンポーネントが必要とするデータの宣言です.
これは、すべてのコンポーネントをフェッチを行うとのようなものですが、フェッチの代わりに、我々は必要なデータを宣言しているだけで、フェッチは一度だけ発生します.実装は以下のようになります:

// page component
graphql`
  query PageQuery {
    user {
      ...NavbarFragment_user
    }
  }
`

// navbar component
graphql`
  fragment NavbarFragment_user on UserType {
    profileImg {
      src
    }
  }
`

このようにNavbar 何が必要かを正確に宣言し、何か変更があった場合、ページの問い合わせではなくフラグメントだけを変更します.

Even though this is nice, we have a problem :(

下方

バージョンでは10 of Relay 我々は、Aを持つことができませんloading indicator コンポーネントごとに、私たちはloading indicator ページ全体で、ユーザーにデータを表示する前に、次のようにします.

あなたはこの問題を解決する2つの方法があります.
あなたは、この問題を解決する最初のアプローチを使用することができますfetch これはfetch 返答しないでくださいloading indicator .
他の方法と私が推薦するものは、あなたのリレーをバージョン11にアップグレードして@defer ディレクティブGraphQL 並んでSuspense コンポーネントReact .
と@defer あなたがあなたの特定の部分を言うことができた指令query , Aのようにfragment , 非同期的にロードされ、その部分のレスポンスがサーバーから返されない場合、loading indicator あなたのSuspense コンポーネント.

Here's the Relay documentation where they explain in more details how to do that and in this video how they're using that on Facebook.

結論

ジャストアスReact かつてはRelay まだ使用されていないライブラリとそのため、それがどのように動作するかを説明する多くの記事やチュートリアルがないため.
私は、この記事が使用方法についてのあなたの理解を増やしたことを望みますRelay あなたのアプリケーションまたはその主なアイデアがどのように動作します.
あなたがより技術的な説明を逃したならば、あるいは、あなたがまだ私がカバーしなかった若干の質問があるならば、無料で感じてください🤙