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.