There is no general answer to this question so we have to evaluate on a case by case basis.
When using Redux, you should strive to keep a balance between keeping reducers simple and keeping the action log meaningful. It is best when you can read the action log and it makes sense why things happened. This is the “predictability” aspect that Redux brings.
When you dispatch a single action, and different parts of the state change in response, it is easy to tell why they change later. If you debug a problem, you are not overwhelmed by the amount of actions, and every mutation can be traced to something a user did.
By constrast, when you dispatch multiple actions in response to a single user interaction, it is harder to tell why they were dispatched. They clutter the action log, and if there is a mistake in how they were dispatched, the log won’t uncover the underlying reasons.
A good rule of thumb is that you never want to dispatch in a loop. This is highly inefficient and, as noted above, obscures the true nature of why the change happened. In your particular example I would recommend firing a single action.
However this does not mean that firing a single action is always the way to go. Like everything, it is a tradeoff. There are valid cases when it is more convenient to fire several actions in response to a single user interaction.
For example, if your app lets users tag products, it can be more convenient to separate CREATE_TAG and ADD_TAG_TO_PRODUCT actions because while in this scenario they happen at the same time, they may also happen separately, and it can be easier to write reducers that handle them as different actions. As long as you don’t abuse this pattern and don’t do something like this in a loop, you should be fine.
Keep action log as close to the history of user interactions as you can. However if it makes reducers tricky to implement consider splitting some actions in several, if a UI update can be thought of two separate operations that just happen to be together. Don’t fall into either of the extremes. Prefer reducer clarity to a perfect log, but also prefer not dispatching in a loop to reducer clarity.