Explore Redux Devtools to Understand Your RTK Query App Data Fetching Behavior

Instructor: [0:00] Now, let's take a look at the Redux dev tools and see what happens internally when we navigate the application. The application has loaded and we see that there happened four actions, the normal Redux INIT action, a middlewareRegistered action and now two more interesting actions, an executeQuery/pending action. [0:22] If we look at that action, we can see that it was for the endpoint pokemonList with a query cache key of pokemonList (undefined) followed by an executeQuery/fulfilled action. Here, we can see that it was for the same endpoint name and the same query cache key. It also contains a payload which is the data that we got back from the API.

[0:46] As you can see, there is not only the normal Redux inspector here, but the Redux dev tools now also feature an RTK query inspector. We click on it and we see that we have a pokemonList cache entry here and we can see the statusFlags.

[1:04] We can see when it was started, when it was loaded, how long the loading took, and we can see more details like the actual data that we received and the status the query is at right now.

[1:19] Now, we can navigate to another endpoint like Ivysaur and we see that we get another cache entry. Looking at that cache entry, we also see all the things we saw before. If we look back at the inspector, we see another pending and another fulfilled action.

[1:38] All of this happens internally. We don't have to set it up in any way and we don't have to care about managing the state. RTK query does it for us.

[1:49] Now, if we wait long enough that Pokemon listing cache entry just disappeared. So going back to the actions, why did that happen? It happens to be the case that here a removeQueryResult action was executed. If you look a little bit further up, we see that an unsubscribeQuery action was dispatched.

[2:12] What happened here was that we navigated away from the listing and as we navigated away from the listing, this unsubscribeQuery action was dispatched. Then a timer started internally waiting 60 seconds if we go back and need that cache entry again.

[2:30] After 60 seconds, RTK query decided nope, we don't need that cache entry anymore, we can remove it. If that 60-second timer is not long enough for you, you can always change that by changing the keep unused data for option either for your whole API or on each endpoint.

[2:47] If we navigate back to the first page, again, we see the other query is going to be unsubscribed now and we have a new request happening. If we go back to Ivysaur though, we just have an unsubscribeQuery happening and we don't really have a pending and fulfilled action happening but instead we see a rejected action.

[3:07] Why a rejection? This case of rejection, if we look at the action, has meta information that shows that it was rejected because of a condition and that means that RTK query noticed that the data already was in the cache and didn't see any reason to start another network request for it.

[3:27] There's also more to explore in the RTK query details. For example, we can go into this Pokemon detail here. We can look at how many components are subscribed to it and if we navigate back, we see that it's unsubscribed. If we navigate towards it again, we see it is subscribed again.

[3:46] We can also see all the actions that were dispatched because of this cache entry like if we navigate forward and backward a little bit, we see another rejection coming in.

[3:56] If we click on API up here, we can also see the full state of the whole API with all the queries, the cache entries, and some more information down here like timings, which query took how long, and which was the fastest request for the server, and stuff like that. Bottom line though, we don't really need to care about all of that.

[4:17] This is stuff that happens internally.