How do you handle request errors or loading states?
RTK Query provides built-in status flags to help you handle loading, success, and error states in your components without manually tracking them. These flags make it easy to manage UI feedback for API requests.
- 1
isLoading: Indicates the request is in progress and no data is yet available. - 2
isFetching: True when data is being refetched, even if cached data is available. - 3
isSuccess: Set to true when data has been successfully fetched. - 4
isError: Becomes true if the request fails for any reason. - 5
error: Contains details about the error (status code, message, etc.).
In this example, isLoading and isFetching control the display of loading messages, while isError and error are used to show appropriate error feedback to users.
For mutations, you can use unwrap() to handle errors with standard try/catch syntax. This gives you fine control over how errors are displayed or logged.
Using these built-in flags, RTK Query simplifies UI state management for network operations, ensuring smooth and reliable user feedback for loading and error handling.
Scenario Questions
0-2 years experience
- 1Imagine you have a component that fetches a list of products using RTK Query's `useGetProductsQuery`. How would you display a spinner while the request is in flight and show an error message if it fails?
- 2If the `isLoading` flag from an RTK Query hook never becomes false, what could be wrong in your component's rendering logic?
2-5 years experience
- 1You need to add retry logic for a failing API call using RTK Query. Walk me through how you'd configure the endpoint and how you'd surface the retry status to the UI.
- 2During a code review you notice that a component is checking both `isError` and `error` from the query hook, but the UI still shows a generic message. What might be causing this and how would you fix it?
- 3Suppose the backend returns a 401 error for an expired token. How would you handle this globally in RTK Query to redirect the user to login while also showing a loading state during token refresh?
5-8 years experience
- 1Design a pattern for handling loading and error states across dozens of pages that use RTK Query, ensuring consistent UI and minimal boilerplate. What abstractions would you introduce?
- 2Your app experiences a performance regression because every component re-renders on any query's loading state change. How would you refactor the state handling to avoid unnecessary renders?
- 3Explain how you would integrate RTK Query's error handling with a centralized toast notification system while still allowing per-component overrides.
8+ years experience
- 1We are migrating a legacy codebase that uses manual thunk actions for data fetching to RTK Query. What strategy would you use to phase in RTK Query while preserving existing error/loading UI, and how would you manage the long‑term maintenance?
- 2Across multiple teams, you need to enforce a company‑wide policy for handling API errors (e.g., logging, user feedback, retry). How would you architect RTK Query middleware or baseQuery to implement this policy without each team writing duplicate code?
- 3Consider a scenario where some services return streaming data and others return batch responses. How would you design a unified loading/error handling approach in RTK that scales to both patterns and supports future services?
Follow-up Questions
- Can you sketch the code you’d write for that scenario?
- What edge cases or race conditions might you need to guard against?
- How would you verify that your error/loading handling works in production?