I'm just gonna say I don't think this is a good idea for any real project. In my mind the single best thing about Redux is the use of event sourcing for all application state changes. Get rid of that, and you lose most of the benefits of Redux.
Reducers are a good thing: they force you to think about state transitions in your app in a functional way. By getting rid of event sourcing and reducers, this library encourages you to couple your views and state very tightly. I'd imagine testing components will be very ugly.
Redux itself is the redux-zero: it's all of a few hundred lines of code. We don't need a lighter-weight version of it that misses the principle design decisions.
I have no problem with someone writing their own state management framework after forgetting or before learning the hard lessons that drove the design of Redux, particularly if it's easier to use for people just getting in to web development.
The problem I have is with an author tying their library to Redux, giving those same newer people the impression that it's a simpler, but just as powerful version of the same thing. If they had been upfront about the tradeoffs made here, I would be happy.
Yeah, there's some truth to that. There was actually a good article and related tweets by Justin Falcone a few months ago on that topic [0][1][2], which are excellent reading.
That said, I'm always looking for ways we can make it easier to get started with Redux, improve the learning process, and make the ecosystem better. I filed an issue earlier this year to get community feedback and discuss how we can simplify things [3]. Please feel free to add suggestions to that issue. I'm also always open to ways we can improve the docs as well.
It's very important that people understand _how_ and _why_ the flux pattern is valuable before they start using Redux, especially if coming from an MVC background. Once you understand that, the learning curve drops away revealing an extremely minimal and easy-to-use library.
'Extremely minimal' is hyperbole and 'easy-to-use' is subjective. I disagree with this as an absolute statement. I think there's a trade off, and it potentially harms onboarding for some teams, see my sibling-ish comment.
I agree with your comment, but disagree that all of the concepts you listed need be understood completely when just getting started. Once the flow is recognized (which in my experience teaching others rarely takes more than a single pairing session) there's basically nothing left but a few functions that pass data in a circle. Everything else that you described comes later, and that later doesn't take long.
Not sure why you were downvoted, I agree. Redux brings a high 'concept count', for such a small amount of code. To talk the language of redux you have to understand: dispatch, actions, actions-types, actionCreators, reducers, mapStateToProps, mapDispatchToProps, middleware, provider/connect. You need to know these things, and best practices for them, and potentially some libraries around them to reduce boilerplate.
As soon as you dip your foot into the community you're also going to hear about 'selectors' (reselect) and popular middlewares like redux-thunk and redux-sagas for async, the latter of which brings a lot of concepts of its own, including generators, which you are likely using nowhere else in your codebase.
You probably also need to understand what react-redux is doing with shouldComponentUpdate.
All this should not be hand-waved away by quoting the LOC of redux.
> In my mind the single best thing about Redux is the use of event sourcing for all application state changes.
I hate to be picking nits here, but unless you're actually storing those events, and rebuilding state from those, its not eventsourcing. We already have to deal with a lot of confounded terminology in that space, please don't add to the confusion.
Yes you're technically correct (the best kind of correct). But I'd argue that if you're developing a Redux app without Redux Dev Tools you're doing it wrong, and Redux Dev Tools does indeed store the original sequence of events and give you Martin Fowler's three killer features: Complete Rebuild, Temporal Query, and Event Replay.
I don't know if I'd agree that "technically correct" is the best kind :)
But I do agree that Redux Dev Tools are a great example of what you can do with ES. That's just not application level logic, so I don't think its fair to credit an application developer with applying ES just because a tool they use at development time (not at runtime) does so.
I don't use Redux, but I presumed that the events were stored by default, and state was rebuilt from them during 'time travel' debugging. In a production environment, rebuilding from the stored events is less necessary, and only specialised applications such as rich text editors (e.g. really use it).
Redux's core doesn't store any events or prior state by default. It just does:
currentState = rootReducer(currentState, action);
Time travel debugging is implemented as a store enhancer, which does indeed save the action history and replay it to generate the correct state as you jump between specific points in the history log.
There's also many addons and additional use cases that can make use of recording actions as they occur, such as logging a user's session for later playback / debugging as part of a crash report, or implementing undo/redo functionality.
Events aren't stored by default. You can store them, and it sure makes creating those types of applications easier, but that's more because you've bought at least partially into referential transparency and pure functions in your reducers.
More apps than the ones you mentioned benefit from this though, any undo or revert operation in an applications is leagues easier in the sort of FRP design of redux.
Reducers are a good thing: they force you to think about state transitions in your app in a functional way. By getting rid of event sourcing and reducers, this library encourages you to couple your views and state very tightly. I'd imagine testing components will be very ugly.
Redux itself is the redux-zero: it's all of a few hundred lines of code. We don't need a lighter-weight version of it that misses the principle design decisions.