I read that Redux Thunk is the reliable way to manage asynchronous actions/request. There's nothing much about dispatching actions by other actions.
How about dispatching synchronous actions? I am not sure of thunk approach's performance issues, but can I just dispatch action inside other action creator without defining function inside?
It seems to me that using redux thunk is unnecessary for this need.
Showing and hiding notification does indeed appear to be a good use case for thunks.
David’s answer describes the “default” way of doing several updates in response to something: handle it from different reducers. Most often this is what you want to do.
Sometimes (as with notifications) it can be inconvenient. I describe how you can choose between dispatching one or several actions in my answer to this question.
In case when you do decide to dispatch multiple actions, either just do it sequentially from your components, or use Redux Thunk. Note that if Redux Thunk seems mysterious to you, you should understand what it really is before using it. It only provides benefits in terms of code organization; in reality it’s not any different from running dispatch() two times in a row yourself.
That said, with Redux Thunk dispatching multiple actions looks like this:
function increment() {
return { type: 'INCREMENT' }
}
function incrementTwice() {
return dispatch => {
dispatch(increment())
dispatch(increment())
}
}
store.dispatch(increment())
incrementTwice()(store.dispatch) // doesn’t require redux-thunk but looks ugly
store.dispatch(incrementTwice()) // requires redux-thunk but looks nice
Using Redux Thunk will not have any performance issues. It’s just a nice way of calling functions to which you can hand over your dispatch so they can do it as many times as they want.
It's a mistake to think of actions to state changes as one-to-one. They are in fact many-to-many. Remember that all actions are called on all reducers.
For instance, a single action might trigger several state changes:
function firstReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
}
}
function secondReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
}
}
function thirdReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
}
}
Conversely, the same state change might result from two different actions.
function firstReducer(state, action) {
switch (action.type) {
case ACTION_X:
case ACTION_Y:
// handle action x and y in the same manner
}
}
It might seem odd to handle two actions in the same manner, but this is only in the context of a single reducer. Other reducers are free to handle them differently.
function secondReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
case ACTION_Y:
// handle action y
}
}
function thirdReducer(state, action) {
switch (action.type) {
case ACTION_X:
// handle action x
default:
// ignore action y
}
}
With this many-to-many relationship, it's simply unnecessary to have an action hierarchy. If you have action creators firing multiple synchronous actions, your code becomes more complex and harder to reason about.
