Sounds like you're confusing 'simple' with 'easy'. Rich Hickey does a good job of contrasting the two in Simple Made Easy[0].

The essential part of Redux is only 44 lines of simple code [1]. You can understand everything that it is doing. That is simple. It doesn't mean that it's going to be a great experience to work with (you might want to add some abstraction on top to make it also 'easy'), but it is definitely simple.

[0]: https://www.infoq.com/presentations/Simple-Made-Easy

[1]: https://gist.github.com/gaearon/ffd88b0e4f00b22c3159#file-sl...

You're complaining about a couple different things. That particular reducer example is a bit terse, and could be made more readable. That said, yes, Redux (as a Flux Architecture derivative) does ask you to separate all your "write logic" from the rest of the application. This is explicitly part of the design.

You may want to read Dan Abramov's article "You Might Not Need Redux", where he discusses the tradeoffs that Redux asks you to make, and the benefits you get as a result: https://medium.com/@dan_abramov/you-might-not-need-redux-be4... .

I'm also working on a blog post that will discuss the actual technical limitations Redux requires of you, vs how you are _intended_ to use Redux, vs how it's _possible_ to use Redux. The goal is to clarify where the various common aspects of Redux usage come from and why. I'm hoping to finish the post over the weekend and publish it early next week. If anyone's interested, keep an eye on my blog at http://blog.isquaredsoftware.com .

> you have to switch to the one file where you keep all the data-modifying functions? Seriously?!

Of course not - and I strongly urge you to think through things like this more deeply before writing them off.

Redux is a really good and well-thought-out library. I'm sure you could think of multiple solutions to the problem you just proposed, including splitting that file into multiple files. It would be a shame if you never took the time to understand the library because you got caught up on simple trivialities like this.

Sure you can split the file, but you still have to separate it from the actual UI event handler.

It might be well thought-out but it's more complicated than it needs to be.

Of course, and that's the huge win of Redux. Forcing you to separate out state updates wraps them in a layer of indirection and allows you to operate on them at a higher level than otherwise possible. This makes ordinarily difficult operations simple and elegant. You can use the higher level of abstraction to get undo for free, or replay them to find bugs, time travel, or send them across a server to get a multi user app. What you're saying is "more complicated than it needs to be" is in fact the revelatory idea of Redux.

I reiterate myself: you should try to understand Redux more deeply before writing it off. You are doing it a disservice.

Why do you need this separation to get these things?

In Freezer, you can do transactions directly in your view event handlers, and one transaction is one update, and .on('update', (currentState, prevState) => {…}) you can save the prevState into your undo log. And when you want to separate a data manipulation action, you can use custom events to do so — but you aren't forced to! It keeps simple operations simple.

Are you really just opposed to doing things in different files?

I'm going to divert the conversation away from Redux entirely if that's the case. You should invest in an editor with good "go to definition" support. I had a similar problem, but as soon as I did this, the pain threshold for switching files dropped to nearly 0.

(If that's not the case, do keep on mind that a file separation is totally unnecessary. You could write your state manipulators inline if you wanted. I feel it is a bit organizationally messy, but hey, whatever you like.)

go to definition is still an extra keystroke :P

I'm just excited about Freezer, and don't care much about Redux.

Well I hope you realize that coming onto a topic about Redux and claiming Freezer is better without really understanding Redux internals may not be the best way to proselytize. :)

The size and complexity of your app is an important factor here. If only one view in your app needs to touch the state in a certain way — say, fetching some data from an API and updating a view — then it might make sense to manage that state in your view. But if multiple components in various parts of your app are making similar kinds of calls, it makes sense to manage it centrally, with a file or set of files that can handle common actions.

I think you could swing that, you'd just have to dispatch a more complicated "action" (event/message) from the handler and write a master reducer that expects incoming actions (events) to contain their own state-managing (possibly, though not necessarily, static) method under some common interface, and called that method (returning its result). Basically each action/event would contain its own reducer, which the master reducer would call. Once done (pretty sure it'd be trivial?) you'd never have to look at your master reducer again.

It'd all live wherever you like, and be passed on to the master reducer via dispatch. Handler/"action"/reducer could live together, as you please.

It's possibly I'm wrong, as I've never done this, but I don't see why this or something fairly similar couldn't work, with little set-up.

That's actually technically possible with Redux, although it's generally considered bad practice.

Nothing is stopping you from putting the functions into multiple files.

There's a critical mass where I switch to using Ducks: https://github.com/erikras/ducks-modular-redux

Yes, you can write bad Redux code. That doesn't mean it's not simple.

Redux gives you a combineReducers() function for splitting your reducers into separate files. The way I structure it is by which section of the state object they modify, so that I have a reducers/stateA.js, reducers/stateB.js, which correspond to a state object that looks like { stateA: { ... }, stateB: { ... } }.

I think it's definitely worth considering other solutions, as Dan himself has mentioned that Redux isn't for everyone. Redux forces you to apply some constraints and make some tradeoffs. I personally like those constraints and tradeoffs, but I can understand it's not for everyone!

"simple" and "verbose" are not the same thing. I agree that Redux is overly verbose, but what it's doing is actually very simple. That said, I avoid it because I dislike having to write actions for every single operation I want to do on my data.

To be fair, you can (and should—I really don't get the appeal of the typically-presented way of using Redux) do things very differently if you like. It's not hard to group actionCreators (actions), actions (events/messages—Redux terminology is pointlessly n00b-hostile), and reducers, and even stick them somewhere closer to (in if you really want to) your views.

If there is one valid criticism of Redux, it is that the names for everything are obtuse and hard to understand.

That, and that the tutorials/beginner-docs don't all start, "look, it's pretty much just two really really simple event dispatchers stuck together, so don't panic" followed by an implementation-focused walkthrough like this.

Redux is way too simple to justify the amount of writing there is trying to teach people to use it[0]. It's two event/message dispatchers. Events/messages move through them thusly. Here's the tiny interface by which you interact with them. Don't do this or this unless you want bugs to happen, and here's why. Done.

[0] a sure sign FP-fans are involved [rimshot]

I couldn't agree more strongly. Something weird happens to FP proponents such that once they get very good at it, they lose all ability to explain or empathize with beginners. :)

One of the most frustrating thing about FP land is that I never feel confident I actually understand anything. Every time I think I might the explanation I arrive at is so damn simple that I can't convince myself it's truly correct because there's this mountain of confusing explanations in my wake, and why would anyone have tried to explain it that way if it were actually this simple?

Docs PRs welcome! :)

(Seriously, I mean it - most of my work as a Redux maintainer has involved improving the docs, and I genuinely am interested in having people help improve them.)

For what it's worth, most of that comes directly from the Flux heritage. For example, the Flux docs at https://facebook.github.io/react/blog/2014/07/30/flux-action... explicitly describe the terms "actions" and "action creators" . There was a lot of discussion and bikeshedding in the early Redux issues over whether to use terms like "events", "commands", or even "facts" instead, but Dan and Andrew opted to keep "actions" for consistency with Flux. (Really, a very large percentage of questions about "Why does Redux do $THING?" can be answered with "Because the Flux Architecture, or other existing Flux libs, did things that way first".)

"Reducers" come from the similarity with the callbacks passed to `Array.reduce()`, "thunk" is an existing CS/programming term, and "saga" was also adopted from the backend world. So sure, a lot of these terms are new to most people (especially front-end developers), but they were generally based on existing terminology and not just picked out randomly.

It's not that I don't understand there were reasons for choosing the names. I just think they were confusing reasons. :)

It reminds me of Haskell, where monad is such a terrible name. Same with functor, applicative functor, etc. Yes, all these names aptly and mathematically describe what they do, but the most precise name will not help beginners understand.

For instance, if reducers were called "state updaters", I think people would be less confused. Same if "map state to props" was called "get props from state".

Sometimes you gotta give up on giving the most precise name and instead give a name that is the most clear for the greatest number of people.

FWIW, I agree with you--I feel like there's a distinct "pull the ladder up behind you" notion in the land of bleeding-edge software (not just FP, but I'm lookin' that way), where a vocal and influential chunk of the community has decided (and enough others have followed along) that a certain kind of exclusive specificity and conscious choice of high-level vocabulary matters more than the other people who might benefit from the stuff. And then inertia means things don't get better.

Many programmers are bad at naming things. Many are bad at doc. None of this stuff is actually hard, it's just made hard and made unfriendly in unfortunate ways.

It's lovely how counterintuitive it is that (in this case) "map" reduces state and "reduce" modifies and/or enlarges state.

Not a valid criticism of Redux.

Not a constructive comment :/