I'm very new to redux, so bear with me.
I have some background in event sourcing, and the way it works is similar to redux, but not quite the same. In redux (or Flux in general), there is the concept of an action, that presuambly represents some intent either by the user or the system. There is also the concept of a reducer that responds to those actions by applying each one to the current state to generate a new state.
state +---> +---------+
| reducer | +---> state
action +---> +---------+
However, in event sourcing (ES for short), the concept of an action is distinct from the concept of an event. The typical pattern in ES is that there is an apply function that derives new state from an existing state and an event. So apply is equivalent to a reducer in redux. However, apply relies on a series of events to derive new state, not actions. Actions, on the other hand, are executed by an execute function, which takes the current state and an action, and produces zero or more events. (A good example can be found here, scroll to the Aggregate Module section.)
state +---> +---------+
| exec | +---> [event]
action +---> +---------+
state +---> +---------+
| apply | +---> state
event +---> +---------+
This separation between actions and events is fundamental to wrapping one's head around intentions (actions) to change state, and facts (events) that need to be reconciled into state due to the fact that those intentions were actually carried out.
By conflating the two together, it causes artifacts like creating async actions and async middlewares, while it would be much easier to always keep actions as plain objects, and create async action handlers instead.
In addition, async actions/middlewares tend to produce other actions in response to the original action. The way I look at it, those async actions/middlewares should produce events, not actions, as a result of executing the original action. Those events will then be reconciled by the reducer in the typical manner. This is a much easier to understand pattern.
Middlewares are supposed to implement cross-cutting concerns, like logging or security, not application logic such as action handling.
Obviously I may be a bit biased towards ES, but I'd love to hear your opinion about what it has to offer.
tauren, krebernisak, cimi, ErickSGM, deltaidea and 11 more
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4