Great tutorial.
I recently published an overview of Redux here - https://medium.com/@guptagaruda/introduction-to-redux-and-mo...
I recently published an overview of Redux here - https://medium.com/@guptagaruda/introduction-to-redux-and-mo...
* Plain javascript with jquery - We can surely achieve it but the code quickly becomes a soup of callbacks and events handlers. After a while the code becomes unmanageable. This is pretty much the approach you're suggesting with getters/setters.
* AngularJS's dirty checking is one solution. It works and the code scales in large teams but perf suffers in complex views due to costly digests. It doesn't provide a way to conditionally exclude a sub-view from the digest cycle. This will become the main bottleneck (for perf) as the application grows.
* React and Angular 2/4 - React (shouldcomponentupdate) and Angular 2/4 (onpush change detection) leverages immutability very well to cut down re-render cycles. This is where Redux shines with its immutable way of changing state. It's uni-directional flow is another great benefit to keep the entire flow predictable and maintainable.
I am not saying all these things are needed for every SPA app out there. But these optimizations are needed for complex and performance sensitive applications. Check this out - https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Also, I know keeping application state as a single state tree is nothing new. I started this side project (https://github.com/guptag/FinCharts) almost four years ago with React/Immutable.js without any state management libraries (recently moved to electron from nodewebkit). But this code won't scale in large teams (entire ui state is declared in one file, cannot extend the functionality like Redux's middleware support etc).
('Cause this is why we use Redux.)
There are various ways to debug state in a React app that uses setState. React devtools show each component's state, and you can combine that with breakpoint debugging as per to figure out how you got there.
The inability to examine a time series of data after-the-fact and resume from any point makes this approach significantly, significantly worse. Like, I've done it just as you have, and I'd under no circumstances go back. It's so bad that I've basically built action-pattern systems in other languages (before using Redux, actually).
Functional tooling and composition with managed side effects is fucking awesome and doing otherwise verges on footgunning if it doesn't camp right out there.
I don't have an example with mutable state but for React + Redux, click on the benchmark perf test page @ https://github.com/guptag/js-frameworks. With 1500 tickers added to the page and with an price update happening every 10ms, React/Redux updates the view within 5ms (on my machine) and consistently maintains 60fps. This is when React does the virtual diffing of only one ticker component whose state is changed and skipping the rest (because of React-Redux's immutability checks). It's going to take more time if React spends diffing the entire app for every update (unfortunately, I don't have a measurement with mutable state as I built this page to compare with AngularJS).
We can easily measure and make a call whether immutability is needed for an app or not.