React Relay: Complex mutation fat query - relayjs

Question

I'm creating a voting applications with polls that can be voted. I'm currently stuck on voting for a poll (essentially, creating a vote).
My schema:
(Long story short: polls are accessible from the main store, but the viewer's polls and votes can be accessed directly by him (as fields). votes also are accessible from the min store, but the poll's votes can be accessed also directly by it.
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
...
}
}
}
}
}
This complex schema makes me confused about how should I define my fat query, since it should define all that could be changing.
Here's what can change:
A vote is created (so voteEdge in the fat query).
A vote is added to the votes connection under store.
A vote is added to the votes connection under viewer.
A vote is added to the votes connection under some poll in the polls connection under store.
(only if the viewer is also the poll's creator, which is possible): A vote is added to the votes connection under some poll in the polls connection under viewer.
So my question is how should I express this in my fat query, should this be suffice?
getFatQuery() {
return Relay.QL`
fragment on CreateVoteMutation {
voteEdge,
viewer{
polls,
voteCount
votes,
},
store{
polls,
voteCount,
votes,
}
}
`;
}
Or should I somehow include votes under polls?
getFatQuery() {
return Relay.QL`
fragment on CreateVoteMutation {
voteEdge,
viewer{
polls{
edges{
node{
voteCount,
votes
}
}
},
voteCount
votes,
},
store{
polls{
edges{
node{
voteCount,
votes
}
}
},
voteCount,
votes,
}
}
`;
}
Thanks!

Answer 1

Looks like you have the right idea. When defining your FatQuery in Relay, you should keep your return fields as optimal as possible, since that's the benefit of GraphQL (you don't need to return more than you will use in your client). So your FatQuery should look like this:
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
}
}
}
`;
}
The idea is that you could technically return votes again as a sub-selection of polls; however, there's no need to since you return is under viewer already. this will give you the total voteCount and all Votes in your system. If you wanted to filter the Votes and VoteCount by Polls, then you could do the opposite, which would look something like this:
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
}
}
}
}
`;
}
Hope this helps!