7. How do you pass parameters to a thunk function?
Passing Parameters to Thunk Functions in Redux Toolkit
In Redux Toolkit, you can easily pass parameters to thunk functions created using createAsyncThunk. These parameters are received by the payload creator (the async function inside createAsyncThunk) and can be used for API calls, filtering, or conditional logic.
- 1
1. Define Parameter in Payload Creator: The async function inside
createAsyncThunkreceives the parameter as its first argument. - 2
2. Dispatch with Argument: When dispatching the thunk, pass the argument like a regular function call — e.g.,
dispatch(fetchUser(5)). - 3
3. Use Parameter Inside Async Logic: Use the received parameter in API requests or any business logic.
You can pass any type of parameter — such as an ID, object, or filter — to dynamically control the async logic inside your thunk. This makes createAsyncThunk highly flexible for different API scenarios.
Scenario Questions
0-2 years experience
- 1You need to fetch user details by ID using createAsyncThunk. How would you pass the userId from a component when dispatching the thunk?
- 2If you accidentally dispatch the thunk without any arguments, what will the payload creator receive and how would you handle it?
2-5 years experience
- 1Your team added a filter object to the API call inside a thunk, but the UI sometimes sends undefined filters causing the request to fail. Walk me through how you'd modify the thunk signature and dispatch to safely handle optional parameters.
- 2During a code review you notice that a thunk is accessing a global variable instead of receiving needed data as an argument. Explain why passing parameters via the dispatched action is preferred and how you'd refactor it.
5-8 years experience
- 1We have a high‑traffic feature that dispatches a thunk with a large payload (e.g., a list of 10k IDs). What trade‑offs would you consider when deciding whether to pass that data as a parameter versus storing it in the Redux state first?
- 2Our analytics team wants to reuse a data‑fetching thunk across multiple slices, each needing different query parameters. How would you design a generic thunk that accepts parameters while keeping type safety and avoiding duplication?
8+ years experience
- 1Our monorepo contains several services that each have their own RTK store. We need a cross‑service thunk that can accept parameters from any consumer without tightly coupling to a specific slice. Describe the architectural approach you’d take, including how you’d expose the thunk, version it, and manage backward compatibility.
- 2Legacy code uses thunks that read parameters from the store directly, leading to hidden dependencies. Propose a migration plan to refactor those thunks to receive parameters explicitly, addressing testing, rollout, and coordination with other teams.
Follow-up Questions
- What happens if you dispatch the thunk with the wrong type of argument?
- How would you test a thunk that receives parameters?
- Can you give an example of using thunkAPI alongside the passed parameters?