So, the api is identical to vanilla React component this.state/this.setState, but extracted to a hard-coded global somewhere, and injected back into your component via context?
> With Redux Zero your component can focus 100% on the UI
Radical.
If Redux is too much, just use stateful components. At least that way you can avoid global mutable state ;)
I'm not going to say Redux-zero isn't useful, but if you're just calling some functions that update the state, how is it even related to Redux?
Redux is all about reducers. "Redux" with "no reducers" is an oxymoron, like "pottery without clay" or "cow herding without cows". Redux is a few tools and an ecosystem to support you in handling your state with nested reducers. The value is the predictability you get from using reducers.
I imagine building this was a useful learning experience (and your intro blog post alludes to that), but keep in mind that Redux is much more a way of thinking about state transitions than it is a library for providing them.
The Elm architecture was the original inspiration for Redux, and I recommend running through the rest of the Elm examples [1] to decide if your removals from Redux are worth pursuing. Notably, how will you handle composing your action-reducers? Can you build the "dynamic list of counters" example without compromising the simplicity you're looking for?
[1] https://github.com/evancz/elm-architecture-tutorial/blob/f8a...
I've seen _many_ "Redux, but without $X" libs pop up over the last two years. Their existence isn't a bad thing - after all, Redux itself started as "Flux, but with functions instead of stores".
That said, I do think most of these "Redux-lite" libs are missing the point of why Redux was designed the way it was. Plain action objects and reducer functions are a _very_ important aspect of Redux's design and reason for existence. Without those, there's no straightforward way to track the state updates, implement time-travel debugging, or use the hundreds of middleware that implement centralized behavior.
It's not like Redux itself is an overly large library in terms of LOC, either. If you strip out the comments and error checks, Redux's core fits in under 100 LOC [0], and I've seen miniature versions of React-Redux that aren't much bigger.
Earlier this year, I wrote a pair of blog posts that dig into the history and intent behind Redux, why it's designed the way it is, and the reason why common Redux usage patterns exist: "The Tao of Redux, Part 1: Implementation and Intent" [1] and "The Tao of Redux, Part 2: Practice and Philosophy" [2]. Dan Abramov's post on "You Might Not Need Redux" [3] is also an important read to understand the tradeoffs involved in using Redux, the limitations it asks you to follow, and the benefits you can get in return.
So, while it's great that people continue to experiment with new ideas and build things that are inspired by Redux, I do feel like most of the spinoffs are throwing away the things that make Redux special in the first place.
(Source: I'm a Redux maintainer.)
[0] https://gist.github.com/gaearon/ffd88b0e4f00b22c3159
[1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
[2] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
[3] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Exporting global store and being able to import it anywhere in an application seems like a bad idea. The nice part about redux is that the store is dynamically injected into react components.
Now the action creators and react components that use action creators are not pure functions the predictability and testability of the application is lost.
It seems appropriate that the README does not contain a "how to test" section, which is a huge selling point to Redux. "Predictable" is also missing.
For sake the of "lite"ness we have lost two huge selling points to use redux.
I love HN because just reading the introductory blog, I sensed design smells and was trying to articulate to myself why I didn't like Redux-Zero. The comments that preceded this one beautifully articulated this. Thanks!
This has nothing to do with Redux, so why call it Redux-zero? If you don't need testability, time traveling, and other Redux core features, then don't use Redux. Just create your own state management system.
What sets this apart from the existing state management systems like redux, mobx, or just plain `setState`? It looks like it gets rid of the redux boilerplate, but mobx already does a fantastic job of making a state container and actions, so I'm not really sure where this stands.
In other words, what's redux-zero's "killer feature" that'll make me switch?
Model - Redux-zero Store
View - ReactComponent
Controller - Redux-zero Actions
Having free access to state (read and write) within actions is a large difference from Redux.
Why do you need a provider?
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.