Not exactly targeting 5 here, but hopefully a worthwhile point.
Redux is a permutation of Event Sourcing (as is Elm's Model-View-Update pattern on which Redux is based), implemented on top of React. ES has a good explanation here but from a server-side perspective.
In traditional event sourcing vernacular, Store is a view (or model), Action is an event, Reducers are event handlers which update the view, Subscriptions are just notification that an event happened, presumably so you can examine the resulting state. Redux is missing a piece to represent side effects. (e.g. calling an API) There are middlewares which have sprung up to try to handle this.
The event sourcing pattern is how the "time-traveling" debugger works (in both Redux and Elm). When the debugger is enabled, it keeps all Actions that have been dispatched, and allows you to tweak or deselect them. So if you remove an action, it reruns the reducer with all actions except that one. It's like you rewrote history. Or you can replay all but the last 5 Actions to "go back in time" by 5 steps.
Redux is a silly concept. Combination pubsub and global variable. But the author take it very seriously. Build as framework, has ability to customize and plug in. And also great tooling such as time travel.
In the end, the author prove good insight. Global variable is good for client application
My suggestion is use redux if you need time travel. If not, event emitter is much simpler
I certainly would not dismiss Redux. Sometimes the simple patterns are the most powerful, such as having one store. On the server side, the particular piece of architecture which is (almost) represented by Redux is considered one of the hardest to understand. So kudos to the author for making something hard seem trivial.
Not to say that Redux goes far enough. In comparison with a Process Manager (and with Elm), Redux is missing a baked-in representation of side effects. That would make it more or less complete.
action creators with state objects do help time travel debug but they prevent proper typechecking, to get around JS problems. if using typescript they get in the way.
I also prefer event emitter because the pub/sub API is so much clearer.
but redux connect() does automate some processes you'd have to setup yourself otherwise
and mapStateToProps to filter which events you want to sub to.
All this could be done with a much simpler event emitter module though.
Usually when i adopt redux I'll wrap in my own TS code to hide the boilerplate in a single place.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not exactly targeting 5 here, but hopefully a worthwhile point.
Redux is a permutation of Event Sourcing (as is Elm's Model-View-Update pattern on which Redux is based), implemented on top of React. ES has a good explanation here but from a server-side perspective.
In traditional event sourcing vernacular, Store is a view (or model), Action is an event, Reducers are event handlers which update the view, Subscriptions are just notification that an event happened, presumably so you can examine the resulting state. Redux is missing a piece to represent side effects. (e.g. calling an API) There are middlewares which have sprung up to try to handle this.
The event sourcing pattern is how the "time-traveling" debugger works (in both Redux and Elm). When the debugger is enabled, it keeps all Actions that have been dispatched, and allows you to tweak or deselect them. So if you remove an action, it reruns the reducer with all actions except that one. It's like you rewrote history. Or you can replay all but the last 5 Actions to "go back in time" by 5 steps.
Redux is a silly concept. Combination pubsub and global variable. But the author take it very seriously. Build as framework, has ability to customize and plug in. And also great tooling such as time travel.
In the end, the author prove good insight. Global variable is good for client application
My suggestion is use redux if you need time travel. If not, event emitter is much simpler
I certainly would not dismiss Redux. Sometimes the simple patterns are the most powerful, such as having one store. On the server side, the particular piece of architecture which is (almost) represented by Redux is considered one of the hardest to understand. So kudos to the author for making something hard seem trivial.
Not to say that Redux goes far enough. In comparison with a Process Manager (and with Elm), Redux is missing a baked-in representation of side effects. That would make it more or less complete.
Agreed!
action creators with state objects do help time travel debug but they prevent proper typechecking, to get around JS problems. if using typescript they get in the way.
I also prefer event emitter because the pub/sub API is so much clearer.
but redux connect() does automate some processes you'd have to setup yourself otherwise
and mapStateToProps to filter which events you want to sub to.
All this could be done with a much simpler event emitter module though.
Usually when i adopt redux I'll wrap in my own TS code to hide the boilerplate in a single place.