thomasabishop/eolas
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Last Sync: 2022-11-19 16:00:05

Browse source
This commit is contained in:
tactonbishop 2022-11-19 16:00:05 +00:00
parent 4a9d9c44dd
commit 90e6010742
1 changed files with 18 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

20
Databases/GraphQL/Apollo/Using_arguments_with_Apollo_Client.md
View file

@ -35,7 +35,7 @@ type Query {
type Track { type Track {
id: ID! id: ID!
title: String! title: String!
author: Author! authorId: String! // They added this on the sly
thumbnail: String thumbnail: String
length: Int length: Int
modulesCount: Int modulesCount: Int
@ -141,7 +141,7 @@ It's not obvious how the resolver should respond to the nested query here since
type Track { type Track {
id: ID! id: ID!
title: String! title: String!
author: Author! authorId: String!
thumbnail: String thumbnail: String
length: Int length: Int
modulesCount: Int modulesCount: Int
@ -156,3 +156,19 @@ type Author {
photo: String photo: String
} }
``` ```
This is where we use a **resolver chain**. Because `authorId` exists on `Track` we can use this to get the `name` part of the query. We already have a resolver for `author` under the `Track` resolver:
```gql
Track: {
author: ({ authorId }, _, { dataSources }) => {
return dataSources.trackApi.getAuthor(authorId);
},
},
```
Notice that `authorId` is used in the place of the `parent` parameter. It already exists on the `Track` that we return from the query. So this can be invoked to fulfill `author` and thereby access the author name from the `graph`.
> I don't really understand this but the general point seems to be that the resolvers outside of the main `Query` block in the resolver are tied to a data type and can be used to magically populate query requests for nested fields providing a key is on the main datatype returned.
Now repeat this example with `modules`