Understand the RTK Query Mental Model Compared to Redux Thunks
In redux we typically model network fetching and caching like this.
- You have a component, which subscribes to data from the redux store via selectors
- In a useEffect hook you check if the data doesn’t exist and then dispatch a thunk
- Your thunk will use a tool like fetch or axios to grab data from over the network
- As it fetches data your thunk will dispatch actions into the redux store such as pending, fulfilled and rejected (error).
- This is complicated to setup and maintain
RTK Query provides a better way.
RTK Query generates hooks for you at runtime that allow you to query and cache data or run mutations. Loading and error states are available automatically in your component via the hook and cache invalidation is easily manageable.
In this course we’re going a take simple website for a dog grooming company written in react and redux and bring in RTK query over a number of lessons. The network data will all be powered through a REST API using mock service worker.
So go ahead checkout the git repo, download the code and get ready to learn how to move your app from redux to RTK query.
Note:
In the video I say "without having previously used similar interfaces like RTK query or Apollo Client" and what I meant to say was "React Query or Apollo Client".
Jamund Ferguson: [0:00] Hi, my name is Jamund Ferguson, and I'm going to take you on this journey from Redux to RTK Query. I've been using Redux and Redux Toolkit in production applications since the very beginning. An RTK Query represents a huge shift in how we think about fetching and caching data from over the network.
[0:17] Without having previously used similar interfaces like RTK Query or Apollo Client, it took me a while to wrap my head around exactly how RTK worked and how to use it. It was so worth it when I figured it out.
[0:30] I put together some diagrams in these lessons that I hope will help you out, and I'm convinced you will love using RTK Query after you've completed this course. Thank you so much for watching.
[0:40] In Redux, we typically model network data fetching and caching like this -- First, you have a component that subscribes the data from Redux via selectors. In the useEffect hook, you check if the data doesn't exist.
[0:52] If not, you dispatch a thunk. Your thunk will use a tool like Fetch or Axios to grab data from over the network, while dispatching various actions along the way to keep your component up-to-date with various states like pending, fulfilled, and error.
[1:08] Anytime the store receives those updates, your component will be re-rendered with any changes to the subscribe state. Even with Redux Toolkits helpers like createAsyncThunk, setting this all up can be pretty confusing. Thankfully, RTK Query looks nothing like this.
[1:26] You simply declare all of your API calls in a single file and use custom hooks to query that information from a component calling Fetch, connecting to your Redux Store, dispatching actions.
[1:39] None of those are things that your components have to worry about at all. All you have to do is define your API and tell your component to subscribe to it using the custom hook that RTK provides for you. Then, things like loading states, error states, and even cache invalidation, all come for free.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!