I can't say I see much benefit in bolting another random library on top of my web stack.
Also, this seems like it's really going out of its way to twist familiar redux patterns into something OOP and class-based. Mashing together these wildly different mental models to solve the same state problems does not pass the "smell test."
Check out the first code sample. It cuts the Redux To Do example code in half (from 36 lines to 18), while still being just as readable/maintainable if not more so.
The first code sample has a lot of unneeded redundancy to begin with. Also... `this.foo()` is not more readable than `foo()` and you're creating an object context for no value add and complicating testing.
@machineghost
> It cuts the Redux To Do example code in half (from 36 lines to 18), while still being just as readable/maintainable if not more so.
Less code does not automatically infer better readability let alone maintainability. This library adds an unnecessary layer of complexity to state management that one has to wrap their head around in order to understand, extend or refactor the codebase.