The beauty of redux itself is the lack of magic. It's essentially just a design pattern and is trivial to follow.

So the "edit" part of your comment is key here: frameworks built on top of redux, including middlewares, store enhancers and stuff can definitely lead to an app that is hard to reason about with side effects happening in places you don't expect.

IMO that ends up being the worse of both world: even with all that tooling, Redux is far from terse (in favor of being explicit), but you also get the drawback of a deeply layered framework. This isn't worth it. There are other frameworks and tools that do this better. If you want to be terse, and don't mind throwing in a lot of layers on top of your code to achieve it, use one of the countless other (mainstream!) solutions to do so.

Redux really excel at "putting the code in your face", giving you easy to follow logic where very little is abstracted (and when it's abstracted, it's just via simple function composition). And at doing that, it is amazing and is my pattern of choice. At anything that diverge from that though, it is so bad it's not funny. Right tool for the right job :)

Redux is difficult to reason about because side-effects can be triggered from anywhere in the application by middleware.

If you're using something like redux-thunk, a single dispatch can cause both a store mutation AND trigger a side effect, which is confusing. I'd rather have those be 2 separate concerns.

Those dispatches can be triggered from anywhere in the app, and multiple middlewares may trigger multiple side-effects in new and exciting ways.

I find that logic to be difficult to follow and test.

I wish it had a more opinionated way to do side-effects, but the solutions like redux-saga seem even more complicated and confusing.

You should checkout https://github.com/jumpsuit/jumpstate

It's much easier to reason about, including side effects, while not being too magical.

yup. Its like i said: redux is simple. Middlewares are what makes it complicated.

Redux-loop had a nice model for side effects, but the syntax did not mesh well with javascript limitations. Redux-saga is nice for testing, but it adds new non-standard concepts on top of generators that make it complicated. I really like the Netflix solution (redux-observable).

Since JS is not Haskell, side effects can be shoved to the side a bit, but there aren't a whole lot of ways to make them nice.

CycleJS probably has one of the better systems. In Redux, even without redux-observables, if you closely follow redux semantics I find that reasoning around thunks works quite well (if you're making sure that your actions are semantic and not glorified setters)

+1 for redux-observables, I've found RxJS to be an excellent tool for managing async without going insane.

I'd also second the notion to be rigorously consistent in following the semantics. I always end up regretting shortcuts.

Depends on how you use it. I just keep my application state in redux.

Redux itself has absolutely no magic. The only "magic" I see is when you add state diffing and memoization (reselect). And even in this case, it's not really hard to understand what's happening.

React with redux is just a big pubsub system, how you set up your application state and how each component interacts with that state will decide how "tangled" and hard to maintain your code is.

Reselect is super opaque. Very difficult to understand what is happening with reselect from my experience.

Agree with all your other points though.

Redux Form really goes against the spirit of Redux in my opinion. It uses Redux internally, but you can't really directly access the reducer it uses, so from the user's perspective it is almost like it's not using Redux. The one serious library choice mistake I made in my first React/Redux app was using Redux Form. It was almost impossible to do things if the library hadn't anticipated my exact use case. I ended up having to rip out a bunch of code, and I switched to React Redux Form[1] even though it was a very immature library at the time.

[1]: https://github.com/davidkpiano/react-redux-form

Honest question, what is the reason for using a global store for form validation? That seems like the ideal use-case for local component state.

In my case, I had an editor for a structured document where the user could modify some parts of the document using a form and others using other components, some of which used forms internally. I wanted to have the whole document represented as an object in my Redux store that was also synced to the server.

Gotcha, thanks!

Seems a shame that Redux-Form (and similar) are presented for more trivial solutions than yours. I don't see many forms that also need modification via 'other components', in a way in which that state can't just be handled by a sensible parent component.

"Too much magic" is a serious stretch. Running through the tutorial here: https://egghead.io/courses/getting-started-with-redux, you pretty much reimplement the whole thing. It's just not that much code. There's plenty of optimizations and edge-case handling in the production version, but overall there just isn't much.

> you lose the concept of independent components

How? Components take props. They're just as independent as they were previously.

> everybody is notified of the inner state of each component

This... isn't the case.

Redux (and Flux in general) is useful when there is application-level data that needs to be shared across different components, and otherwise something ends up being a prop to a bunch of things that shouldn't be. Or when you want something to remain around when components go out of scope. If you don't have this problem, Redux is overkill. For larger apps, it's damn useful.

It's not redux itself which has too much magic in it, just your application flow that becomes magic when using redux.

> How? Components take props. They're just as independent as they were previously.

But in raw react it's straitforward: props are properties passed in the jsx tag of the element. With redux your props just pop out of nowhere when some event is dispatched somewhere in your code and your (smart) component can also change any other component's state without you knowing it. I know this kind of behavior can be useful sometimes (because you exactly want to do that) but in many situation you don't need it (in the same app I mean).

My problem with redux is that it makes the remote control implicit instead of explicit. Plus you don't always control redux by yourself but are also encouraged to use a lot of librairies that tamper the global state behind your back: redux-router, redux-form, etc.

I don't think its really all that magical when looked at as a giant component. In the context of the react-redux lib, its really similar to just having one large top level component that contains your entire state and all methods you would want to commit (but instead its called a store and actions). Everything is still unidirectional in that it has to go through that main redux provider and then gets passed back down to all the children, without the need to pass around every single possible method to each child.

So even if you have two "smart" components they are still just children of that main redux provider and therefore it makes sense that they can impact each other. The same way children can call methods that change a parents state on normal react components.

The "container component" pattern is widely used throughout the React world - it's simply any component whose primary responsibility is retrieving some data, and passing that as props to children. Could be making an AJAX call in `componentDidMount`, or something else. In this case, the container components generated by `connect` simply manage a subscription to the Redux store, retrieve the current state when notified, and run your `mapState` and pass the result down. Absolutely no magic at all, and definitely not "also changing any component's state without you knowing it".

Dan Abramov wrote a simplified version of `connect` to illustrate what it does: https://gist.github.com/gaearon/1d19088790e70ac32ea636c025ba... .

As for other libraries, they're still dispatching actions, which means that all updates to the store are traceable (especially if you're using the Redux DevTools).

The caveat here is that with flux/redux, I'd argue "make as few components as reasonably possible interact with redux" is a best practice. If "things popping out of nowhere" is a problem, you probably have too many components listening on your stores.

That was actually the early advice for how to use Redux, but experience has shown that leads to less than optimal performance. In fact, benchmarks show that _more_ connected components usually leads to better perf, as the cost of notifying more subscribers is less than the cost of more wasted re-renders.

See the following links for more info:

- http://blog.isquaredsoftware.com/2017/01/practical-redux-par...

- http://redux.js.org/docs/faq/Performance.html#performance-sc...

- http://somebody32.github.io/high-performance-redux/

Most performant and easiest to follow/debug/reason are often not the same thing.

Thanks for the links !

Global state vs. local state is a problem with several tradeoffs that I don't think anyone has nailed. You might be interested in the discussions and solutions people are developing here: https://github.com/slorber/scalable-frontend-with-elm-or-red...

Thanks !

Consider MobX, it's just getter-setter pairs for actual change detection. It's the declarative reactive one-way flow binder you want. It saved me a lot of time.

People think redux is about functional immutable stuff. It's not functional and state is obviously not immutable (then nothing would happen). Redux is just about "what's the smallest thing we can do to get React to know when to render" and the answer is "put everything in one function".

It's a great educational tool but I don't get why people build big things with it.

Thanks, I'll have a look at it.

Edit: The first result for MobX in the French version of DDG is a porn site xD.

I really don't think this is true. Redux is simple, and by using the react bindings, you get perfect encapsulation: components take props which can be from the state (so your component needs no knowledge of the state store) or action creators (which makes for easy test mocking). If anything, this makes your components a lot easier to read and reason about (and test).

The thing I don't like in Redux is all the boilerplate code required to make simple things. I understand that in some point you may want/need to switch over to Redux but to start some projects I'm always considering a simple Event Emitter like node-events.

Obligatory link: Dan Abramov's article on "You Might Not Need Redux", discussing the tradeoffs involved in Redux: https://medium.com/@dan_abramov/you-might-not-need-redux-be4... .

Also, Dan has pointed out that the Redux docs were written in a deliberately verbose style to illustrate what's going on, and people sorta followed that. There's plenty of ways to reduce the boilerplate, and you're welcome to do that as much as you want.

Redux uses Event Sourcing. ES's trade-offs apply.

Its evented, not normally event-sourced. I don't know of many production uses of redux that also store the events for replay.

Redux in its essensce encourages half assed event sourcing.

Why do i need to memoise my state to stop the react render loop from happening? Isnt my event the source of truth? Its much more then a DTO.

Once your application becomes "event centric" instead of "state centric" you start to actually break free of the procedural paradgim and really become functional reactive.

Redux to me is DDD and ES for non-programmers. My domain logic is the gatekeeper to my state, and as such, should be coupled together. I dont combine my aggregates, just the same way i dont combineReducers. Code smell much.

An app really becomes an app instead of a view layer for a CRUD API once you start adding in business logic, permissions, unstable networks, etc. I'd love to see a Redux example app that handles those things as cleanly as it handles simple cases.

Addtionally;

Why apply your event to the state, then somehow sync your state with the server.

Wouldnt it be simplier just to sync your events?

Yeah, its simpler, I just don't see many applications doing it. Additionally, not all events need to be synced, some need to be enriched before being synced... by the time you've done all that, you're almost back to syncing state. Which is probably why we don't see many apps doing this with redux.

Redux is much more closely aligned with CQRS principles than ES.

this is the first time i've ever heard someone complain of redux having too much magic

most people complain there is too much boilerplate!