リアクションリレー：複雑な突然変異ファットクエリー

Question

私は投票が可能な投票アプリケーションを作成しています。私は現在投票（本質的に、投票を作成する）に投票しています。

マイスキーマ：

（かいつまん：世論調査は、メインストアからアクセス可能ですが、視聴者の投票や票は、（）フィールドとして彼から直接アクセスすることができ票も分店からアクセスできます。しかし、世論調査の投票は、それによっても直接アクセスすることができます。

query { 
    store { 
    polls { //poll connection 
     edges { 
     node { //poll 
      votes { //vote connection 
      ... 
      } 
     } 
     } 
    } 
    votes { //vote connection 
     edges { 
     node { //vote 
      ... 
     } 
     } 
    } 
    } 
    viewer { 
    polls { //poll connection 
     edges { 
     node { //poll 
      votes { //vote connection 
      ... 
      } 
     } 
     } 
    } 
    votes { //vote connection 
     edges { 
     node { //vote 
      ... 
     } 
     } 
    } 
    } 
} 

この複雑なスキーマは、それは変更することができること。

ここですべてを定義する必要があるため、私は、私の脂肪クエリを定義する方法について、私は混乱します'変更可能なもの：

1. 投票が作成されます（太いクエリではvoteEdge）。
2. ストアの投票接続に投票が追加されました。
3. ビューアーの投票接続に投票が追加されました。
4. ストアのポーリング接続の投票で、投票接続に投票が追加されました。
5. （閲覧者が投票の作成者でも可能な場合のみ可能）：ビューアの下にある投票接続の投票によって、投票接続に投票が追加されます。

私の質問は、私の太ったクエリでこれをどのように表現すれば十分ですか？

getFatQuery() { 
    return Relay.QL` 
     fragment on CreateVoteMutation { 
     voteEdge, 
     viewer{ 
      polls, 
      voteCount 
      votes, 
     }, 
     store{ 
      polls, 
      voteCount, 
      votes, 
     } 
     } 
    `; 
    } 

投票に投票してもよろしいですか？

getFatQuery() { 
    return Relay.QL` 
     fragment on CreateVoteMutation { 
     voteEdge, 
     viewer{ 
      polls{ 
      edges{ 
       node{ 
       voteCount, 
       votes 
       } 
      } 
      }, 
      voteCount 
      votes, 
     }, 
     store{ 
      polls{ 
      edges{ 
       node{ 
       voteCount, 
       votes 
       } 
      } 
      }, 
      voteCount, 
      votes, 
     } 
     } 
    `; 
    } 

ありがとうございます！

Answer 1

あなたは正しいアイデアがあるように見えます。 RelayでFatQueryを定義するときは、返すフィールドをできるだけ最適な状態に保つ必要があります。これはGraphQLの利点です（クライアントで使用する以上に返す必要はありません）。だからあなたのFatQueryは次のようになります。

getFatQuery() { 
    return Relay.QL` 
     fragment on CreateVoteMutation { 
     voteEdge, 
     viewer{ 
      polls { // this is most likely a GraphQL object type, so you'll need a sub-selection, but you don't necessarily need to return all the Votes again since you do that later 
      name 
      timestamp 
      } 
      voteCount // scalar integer 
      votes { // again, here you'll need to return a sub-selection since Votes is a GraphQL object type 
      name 
      timestamp 
      } 
     }, 
     store{ 
      polls { // this is most likely a GraphQL object type, so you'll need a sub-selection, but you don't necessarily need to return all the Votes again since you do that later 
      name 
      timestamp 
      } 
      voteCount // scalar integer 
      votes { // again, here you'll need to return a sub-selection since Votes is a GraphQL object type 
      name 
      timestamp 
      } 
     } 
     } 
    `; 
    } 

アイデアは、あなたが技術的にpollsのサブ選択として再度votesを返す可能性があることです。しかし、あなたが帰ってからは、すでに視聴者の下にあるので、必要はありません。これはあなたのシステム内の投票総数とすべての投票をあなたに与えます。このことができます

getFatQuery() { 
    return Relay.QL` 
     fragment on CreateVoteMutation { 
     voteEdge, 
     viewer{ 
      polls { // this is most likely a GraphQL object type, so you'll need a sub-selection, but you don't necessarily need to return all the Votes again since you do that later 
      name 
      timestamp 
      voteCount // scalar integer 
      votes { // again, here you'll need to return a sub-selection since Votes is a GraphQL object type 
       name 
       timestamp 
      } 
      } 
     }, 
     store{ 
      polls { // this is most likely a GraphQL object type, so you'll need a sub-selection, but you don't necessarily need to return all the Votes again since you do that later 
      name 
      timestamp 
      voteCount // scalar integer 
      votes { // again, here you'll need to return a sub-selection since Votes is a GraphQL object type 
       name 
       timestamp 
      } 
      } 
     } 
     } 
    `; 
    } 

希望：あなたが投票で投票してVoteCountをフィルタリングしたい場合は、次のようになり、反対に、行うことができます！