
Redux-zero: A lightweight state container based on Redux - uptown
https://github.com/concretesolutions/redux-zero
======
couchand
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.

~~~
gedy
I think you are missing out on the point that Redux can be very difficult to
learn and build a real app around for many people.

> it's all of a few hundred lines of code

I hear this a lot, but it reminds me of folks praising Lisp for its simplicity
- it may be 'simple' but many people have a hard time understanding it.

Maybe it's not for every app, but goes into this here:
[https://medium.com/@matheusml/great-question-bryan-
waddingto...](https://medium.com/@matheusml/great-question-bryan-
waddington-c171027743e2)

~~~
cnp
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.

~~~
allover
> 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.

~~~
cnp
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.

------
jitl
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 ;)

------
tobr
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.

~~~
gwn7
I'm going to add that even the name "redux" comes from the word "reducer"..

~~~
MentallyRetired
And there are zero of them in redux-zero... zero reducers... ;)

~~~
leshow
Still, pretty odd. It'd be like calling Go "Haskell-zero"

------
CGamesPlay
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...](https://github.com/evancz/elm-architecture-
tutorial/blob/f8a944bf0e89062f4f3a60716b7e06d37593627f/README.md)

~~~
leshow
I'd just like to comment that TEA (the elm architecture) has changed a bit
now, and been baked into the langauge. They've made it very tedious to
abstract any state away from global, and so those examples have been removed
(if you look at TEA NOT from 2015). It's an unfortunate thing in the Elm
community that they encourage you to either: A: have an update function that
could grow forever depending on the sizeof your app, B - have to write many
lines of boilerplate and get 'discouraged' from even doing so by the community
because it's not the language's blessed path.

Here is the new TEA doc: [https://guide.elm-
lang.org/architecture/](https://guide.elm-lang.org/architecture/)

Note it never mentions components or how to compose update functions.

------
acemarke
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](https://gist.github.com/gaearon/ffd88b0e4f00b22c3159)

[1] [http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-
tao...](http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-
part-1/)

[2] [http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-
tao...](http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-
part-2/)

[3] [https://medium.com/@dan_abramov/you-might-not-need-redux-
be4...](https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367)

~~~
shados
I think a lot of it has to do with people missing the point of Redux, but
feeling peer pressured into using it "because its what the cool kids do".

I've seen people use Redux and then make a single action, "SET_STATE_AT_KEY"
or something, with a signature in the form: { type: SET_STATE_AT_KEY, payload:
{ key: 'someKey', value: 'someValue' } just so they can use 1 single action
and 1 single reducer everywhere (ok, they usually have a second one to push
into an array).

People who don't believe Redux is the right solution for them just need to
look at the 6 millions totally-not-redux solutions (MobX, Relay, whatever)
instead of using "Redux-but-not-quite". They'll be much happier.

~~~
acemarke
Yeah. I love Redux and will happily promote it, but it's not for everyone, and
there's definitely people out there who insist you _have_ to use it. My own
advice for getting started with React is to focus on React first, then learn
Redux later.

The "single generic reducer" approach is technically valid, and I've seen
several articles where people do that. I discourage that approach because it
doesn't tell you anything meaningful about the _intent_ behind the update, and
it's much harder to trace where that action was dispatched, but it's a legal
way to use Redux. My two "Tao of Redux" posts discussed the intent behind
state changes being semantically meaningful, and both my own thoughts and Dan
Abramov's comments on the "all-in-one reducer" approach [0] [1].

(Also, I should look at who I'm replying to before I write answers. Hi,
Shados!)

[0] [http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-
tao...](http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-
part-1/#action-history-should-have-semantic-meaning)

[1] [http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-
tao...](http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-
part-2/#cursors-and-all-in-one-reducers)

------
qudat
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.

------
hannofcart
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!

~~~
hannofcart
Having said that, I wish I had enough Zen to articulate this on my own. Sigh.

~~~
couchand
It sounds like you have the right sensibility, so you're well on your way!
Taste is the hardest thing to develop, clearly articulating the rationale
behind it just takes practice.

------
oldboyFX
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.

------
eat_veggies
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?

------
ctvo
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.

------
obilgic
Why do you need a provider?

~~~
jonreem
Without the Provider there would be no way for the `connect` decorator to give
access to the current state. Given the design of this library though (global
store) it seems like it would be fine to just pass the store along in the call
to `connect`.

Note that the global store is a huge problem for this library. How would you
use this when writing a component that wants to use redux-zero in a _library_
, not directly in an application?

