18. How can you refactor thunk-based APIs to RTK Query-based APIs?

Refactoring Thunk-Based APIs to RTK Query in Redux Toolkit

RTK Query simplifies data fetching and caching compared to manually managing async thunks. When refactoring from thunk-based APIs, you can move API logic from slices and thunks into createApi endpoints, which automatically generate hooks and handle caching, re-fetching, and status management.

Steps to Refactor Thunks to RTK Query

1
1. Identify Thunk Logic: Locate existing createAsyncThunk calls that perform API requests and return fetched data.
2
2. Create an API Slice: Replace thunk logic with createApi and define endpoints using builder.query() or builder.mutation().
3
3. Remove Manual Status Handling: Eliminate pending, fulfilled, and rejected reducers—RTK Query automatically manages loading and error states.
4
4. Use Auto-Generated Hooks: Replace manual dispatch and selectors with RTK Query hooks like useGetUsersQuery() or useAddUserMutation().
5
5. Delete Redundant Slice Code: Remove async reducers and state properties that are now managed by RTK Query.

Before: Thunk-Based Example

After: RTK Query-Based Example

By migrating from thunks to RTK Query, you reduce boilerplate, simplify async logic, and gain built-in caching, invalidation, and automatic re-fetching for a more efficient and maintainable Redux architecture.

Difficulty: 6/10

Topics: RTK Query migration, cache management, optimistic updates

Scenario Questions

0-2 years experience

1
We have a simple Redux slice that uses createAsyncThunk to fetch a list of products. How would you replace that thunk with an RTK Query endpoint?
2
If you convert a thunk that returns a promise into an RTK Query query, what changes do you need to make to the component that dispatches it?

2-5 years experience

1
During a feature rollout, you switched a user‑profile fetch from a thunk to RTK Query, but the UI stopped updating after a refresh. What could be causing this and how would you debug it?
2
When refactoring multiple related thunks (fetch, create, delete) into a single RTK Query service, what trade‑offs do you consider regarding cache invalidation and optimistic updates?

5-8 years experience

1
At scale, how does moving from thunk‑based data fetching to RTK Query affect network traffic and cache consistency across tabs, and what patterns would you use to mitigate any issues?
2
Design a migration plan for a large codebase that mixes thunks and RTK Query, ensuring minimal disruption to existing features and tests.

8+ years experience

1
From an architecture perspective, what are the long‑term maintenance implications of standardizing on RTK Query for all data fetching versus keeping a hybrid thunk/RTK Query approach?
2
How would you convince multiple product teams to adopt RTK Query for new services, addressing concerns about learning curve, testing strategy, and backward compatibility?

Follow-up Questions

❓What steps would you take to verify that the new RTK Query endpoint works correctly?
❓How do you handle error handling differences between thunks and RTK Query?
❓Can you describe how you would monitor performance after the migration?