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.
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.
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!)
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...