Optimise queries to ensure all entities are normalised in the Apollo cache
If you help Apollo correctly identify objects, by asking the server for their ID, it will normalise them at the root of the cache. This ensures that instead of duplicating data, all queries and all the other entities just reference that single normalised instance. The more normalised entities and references to those entities you have, the more you'll notice components correctly reflecting updates when mutation are made.
Instructor: [0:00] We have a new Edit Categories button here that displays all my three categories, and allows me to edit them and save them if I want. This EditCategories component first makes a query to get all categories and pulls in their ID and label. It also exposes a mutation that makes an updateCategory request with the ID and the new label of the changed category.
[0:27] In the UI, whenever I click the Save button, that's when this mutation is called. My category is selected up here. Instead of using mocked categories, it's now importing the AllCategories query from my EditCategories component that we just looked at, and is now requesting actual categories with IDs and labels.
[0:49] If we change a category and press Save, we can see that it updates in the list as well at the top, which is expected, based on the previous lesson. The mutation that we just made is returning a category, the idea of the category, and the change label. Because we ask for an ID, all of its data is correctly normalized so it gets the update.
[1:15] If we look a bit deeper in our app, even though the list at the top updated, we can see in our notes that we're still pointing to the old label. Let's debug this. We just confirmed that our mutation includes all the necessary fields that we need to update the cache.
[1:33] If it's not that, let's go and actually look at what's stored in the cache. We see my three categories at the root level now and if I open up the first one, we see the updated label. That looks OK as well and it's probably why my change reflected in the drop-down at the top.
[1:53] Then we know that my list of notes is just referencing normalized notes. Let me open up one of them. If we look at the category, interesting. They have a non-normalized object in here. Instead of pointing to a reference of a category, they have the full category. Why is that?
[2:13] Well, if we look at our notes query, we can see that when we're asking for a category, we're asking for its label, but not its ID. Apollo actually doesn't know what to do with this, and it can't normalize it.
[2:28] If we add the ID, go back to my page, and then make a change in here and I press Save, we can see it updates at the top and then it updates in the full note list as well. That's pretty cool.
[2:44] Whenever we make a change now and we press Save, we have to invoke the mutation, but then we don't have to worry about dispatching any other event, a redux action. We don't have to worry about how our components are going to re-render, or making sure that the data from all these components is hooked up correctly to our source of truth.
[3:05] When I update a category here, it updates everywhere in our app where we display that category. It works even if that category is just a sub-field of a note.