Updating the Cache

[00:00:00]
>> Scott Moss: So update, the way it works is, the first argument that you're gonna get in update is you're gonna get a reference to the actual cache object. The cache object is, like I said, it's that internal thing that Apollo is storing all the cache flat when we get back it from queries and mutations.

[00:00:15]
The next thing you're gonna get back is, you're going to get back what looks like a GraphQL response. And that's because it is. So you're gonna get back the GraphQL response from the mutation that you're trying to update. So in this case, they have an ADD_TODO mutation. Whatever your mutation is, that's the response you're gonna get back.

[00:00:34]
You're gonna get back data dot, whatever the name of your mutation was. So in my example, I would get back an object that has a data property data dot addPet. So that's the response that I would get back. I would get back this. And then from there, the objective is basically, what you wanna do is you have to read any query that might be interested in this new resource that you created, right?

[00:01:02]
So in our our example, we only have one query, that's the allPets query. But in other apps, you might have many queries that use pets, lists in many different places, or maybe just this one pet. You might have different places where those pets can be. For every single one of those queries, you have to read them using the cache.

[00:01:20]
So there's a cache.readQuery function here. This readQuery function takes an object that takes a query property, and its just the reference to your query that you created. And when I say reference to the query that you created, I'm talking about the actual query. So in this case, I would pass allPets.

[00:01:37]
That's the reference to my query. So I need the exact, and this is why I said the fields have to be exactly the same. Because GraphQL is gonna go look for that query. And if it's different than what you did before, it's gonna be like, I didn't find it.

[00:01:49]
I didn't see a query in the cache for that, what are you talking about? Because it's watching these queries, so that it has to know, it needs a reference to it. So passing that reference is gonna let GraphQL know, or Apollo know, that this is the query that you're interested in.

[00:02:03]
>> Scott Moss: So once you do that, you'll get a reference back to its data, right? So in our example, we would get back an object that had pets on it, whatever the name of the query was, yeah. So we'd get back an object that had pets.
>> Scott Moss: And then from there, what you wanna do is you wanna use the write query.

[00:02:23]
So once you read the query, now you've gotta write back to the query, just like Apollo does. When you issue a query yourself, when you do use query, Apollo's gonna automatically write that query as a result to the cache for you. You're just doing it manually. You're saying, cool, now I'm gonna take the cache, and I'm gonna write it to the query myself.

[00:02:42]
So for this given query, for GET_TODOS, I'm gonna overwrite it to be this data now. And in this example, you can see that they basically created a new todos array, based off the old todos array concatenated with the new one that they created. So they added it to the end of it.

[00:02:58]
You should probably add it to the beginning so the new pet shows up first, and not the end. But you can do whatever you want. And that's basically it. You need to read from the cache to get the query. And then you need to update the cache with the same query, and completely make a brand new state for that.

[00:03:17]
Don't do mutable operations. Don't do push, pop, don't do any of that stuff. It's immutable, create a whole new thing and update your cache. And make sure it's exactly the same as it would be if GraphQL did it automatically. So how to you know if it's exactly the same?

[00:03:32]
Well, GraphQL is gonna save things the way that they come back. So if you have pets here, then that's how GraphQL is gonna save it. If you alias this to something else, that's how GraphQL is gonna save it. It's not gonna save it as pets. It's gonna save it as things.

[00:03:45]
So you need to make sure yours is following that alias as well. So that's how the automatic cache writes happen, is based off your queries. So you need to make sure since you're doing it manually, you follow the rules based off your queries as well. So in this example, todos, that's the exact query name that was being used for the GET_TODOS query.

[00:04:08]
That's the name of the query. This is the name of the variable holding the query. And then they're just concatenating it to here. Any more questions on this? Yes Radash?
>> Radash: So the component will update twice, once when the response comes back and another time when you write to the cache?

[00:04:25]
>> Scott Moss: So it won't update when the response comes back, because where is it going? I guess it depends on what you're describing as an update. Are you saying-
>> Radash: The component re-rendering, I mean-
>> Scott Moss: The component will definitely re-render, because we're gonna get back a data property on, where's it at, this thing.

[00:04:44]
So yeah, you will have a re-render. But you won't see the app flicker or anything like that. This is all happening at the same time, right? So when you do a new pet, you're gonna do your update. That's gonna cause a re-render. Once you do your update, the cache is gonna update.

[00:05:02]
Once that cache is updated, that's gonna trigger this data to be different now. This data from this query is gonna be different now, and that's gonna cause a re-render. So yeah, it's just like, basically, you're just setting a state. So you get some new data back. You can think of this, this is the same thing that would happen if you had a prop that came in, which will cause a re-render.

[00:05:21]
And then you took that prop and you set a state based off that prop, which will then cause another re-render. That's basically what's happening here. You could think of this as a prop that's coming in, that causes a re-render. And then we're setting some state inside of here that causes a re-render.

[00:05:36]
Any other questions?
>> Speaker 3: So you were saying that, so in the cache, where you're reading the cache, you could have multiple queries?
>> Scott Moss: Yeah, you can read the cache as many times as you want in here, for as many queries as you need, and write to it.
>> Speaker 3: So would that be multiple lines of cache.readQuery?

[00:05:59]
Or is there some syntax where you-
>> Scott Moss: It would be multiple lines of cache.readQuery, yeah.