Simple front-end applications I’ve worked with have one event (click, keypress, input change, etc.), which dispatches a single action to modify part of the application state tree. At the time your application scales in complexity, that single event may need to perform several actions at once and perform some sort business logic before they are dispatched.
A potential solution
Recently I’ve been using Redux Thunk for dispatching a single thunk action, and in turn, it dispatches several actions to modify independent areas of the application state. Think Redux Thunk is only for asynchronous actions? Think again! Never heard of Redux Thunk or the term thunk? No worries, I will go a bit more in-depth about how it works below.
Now let’s pretend you have an e-commerce store, and your application state looks something like this:
Imagine you have a sidebar which slides out from the side of the screen whenever a user clicks a button to add an item to the cart. When doing so, you might dispatch two separate actions: one for adding the item to the cart, and the second for telling the view that the sidebar should be opened.
This button component would generally be a nested deep within the application hierarchy. In the future, you might want to have this same functionality in a completely separate component. This would be problematic since you now have two areas of your application which are performing the same set of logic.
You can see how this defeats the DRY principles of software development. Instead of dispatching several actions from within a component, try separating them into a thunk action.
Here I’ll update the button to fire a single action, which also gives you the benefit of one less property to pass down.
Building a thunk action
Let’s try to break this down. The thunk action
addItemToCart is a function, which accepts the cart ID as an argument and then returns another function. When you dispatch any action, the Thunk middleware will check if the current action type is a function and if it’s true, it will call it, and pass the Redux
getState as the arguments.
This is a pretty simple example, so let’s make it a little more complicated. You now need to save the item to the backend to allow the cart to persist between sessions.
Did you know that you can trigger other thunk actions from within a thunk action? You are not limited to only dispatching actions which have a return value.
Now instead of only passing the ID to
addToCart, we’ll pretend the reducer requires the entire item to be sent instead. With these new requirements, you can call
getState to return the merchandise from the store, and find the value you need to send.
Testing a thunk action
Testing thunk actions are a little bit different than testing regular actions. The main difference is we are no longer testing the returned value of an action, and instead of testing whether the dispatch is called with the correct values.
What I love the most about this approach is that all the logic is contained within a specific area of the application. It’s entirely out of a component, which helps keep them “dumb”. Luckily, thunk actions are super simple to test, which gives you no reason not to test them. Whether you have thoughts of using this solution now or in the future, know that it will be able to handle your challenging workflows.
This article has been written and updated to support the following versions:
- Redux: 4.0.0
- Redux Thunk: 2.3.0
- Jest: 23.2.0