Ryan Chenkie: 0:00 We have a small GraphQL server which deals with state and city data. We have a type of state and there're a few items on it. One of them is a list of cities that we can get for each state.
0:11 That uses the city type that we have here. In the root query, we just have one item though, and that is states which returns that list of states.
0:20 Here are some data for states and for cities. Down here in the resolvers, just a single resolver right now which returns states. Run the query over here and we can get our list of states.
0:31 Now, since on our schema, we're saying that state has a list of cities, it's tempting to come up here and say, "Give us cities for each of the states." If we do that, we'll just get null for everything right now.
0:44 That's because even though we have cities here on our schema for our states, we don't actually have a way to handle putting these two datasets together yet.
0:53 Since our states data itself doesn't have a key that says cities to give us a list of cities, we need to handle this in another way.
1:02 Come down to the resolvers, and put in a new resolver object. Call it state. The state resolvers object should have a resolver of cities.
1:14 For now, we can just return our list of cities, and we'll see the problem with this right away. When we query for cities on each of our states, we get all of our cities.
1:23 Obviously, this doesn't work because Providence, Rhode Island is not in California. To fix this, we can filter our cities based on the state ID that we have in the cities objects.
1:35 To do that, we'll use the parent object here in our cities resolver. Parent is an object that contains information about the resolver that ran just before. GraphQL resolvers are nested, meaning that we will get here in the parent anything from the query resolver that ran just before it.
1:53 Return the cities for now just so we can see how this works. What we've got here in the console is the data that's coming out of this states resolver.
2:04 Because of how GraphQL resolvers are nested, the states resolver runs first, and then the cities resolver, meaning that we can get information out of the resolver that is the parent to this current one.
2:16 Filtering now becomes pretty easy. We just return cities and we'll run a filter on it. We'll take a city. For that city, we will have a predicate that says return the city if the city.stateId === parent.id.
2:33 Run that again, and we are now scoping our cities to the states in which they belong. A common practice here is to name the parent object based on what it is referring to. Instead of just a generic parent, we can call it state.