[hising]

I don't understand Redux, I have almost 20 years of coding (I probably suck at it though). I once asked a developer at an interview if he could explain the redux stuff he had used in an assignment. He couldn't and I really tried to understand all the boilerplate and inner designs of the library, but I found it really hard to get into. Mobx though, 2 minutes and you get it AND you get more efficient in building complex UI:s.

[batmansmk]

You started on the wrong foot. Learning from someone who cannot explain his own code is not the right context to learn any tech.

Redux is a modern implementation of CQRS/Event sourcing, a design pattern that existed before you even started coding. Many developers, in different languages, learned it and used it (if you want to implement an undo stack for instance, there is not a lot of other solutions around). Trust yourself and your intelligence. Our devs learn it in about 3h with our training program and get a return on investment in about a week.

MobX is nice and if it fits you, go for it. If you are a hands-on kind of guy, you may discover the limits of MobX by using it, and from the trenches finally understand why Redux, and why does it need 3 objects (a store, a reducer, an action).

[acemarke]

I'd be happy to answer any questions you might have about Redux if you'd like. The Reactiflux chat channels on Discord are a great place to hang out, ask questions, and learn. The invite link is at https://www.reactiflux.com . Feel free to drop by and ping me.

Also, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics. It includes links for learning core Javascript (ES5), modern Javascript (ES6+), React, and much more. I also published an "Intro to React (and Redux)" presentation at http://blog.isquaredsoftware.com/2017/02/presentation-react-... , which is a good overview of the basic concepts for both React and Redux.

[pivotal]

I learned the unidirectional data flow pattern with flux before redux and redux makes flux look like war & peace! :P

The no frills way I like to think about redux is your rendered page is the result of a function operating on a state object. Changes to the state object trigger re-renders. There's obviously some subtleties in there and complex use cases, but that's the basic gist.

[ashark]

It's two event/message dispatchers slapped together. One for "reducers" that take an event/message and apply it to state, one that automagically applies the resulting state-change event to do stuff to your views. You mostly don't need to worry about the second one.

As far as I can tell, that's it.

For bad reasons they've decided to stick with the terrible "action" name for their events/messages, which has made the whole thing super confusing (turning "actionCreator" into "eventCreator" immediately makes things much clearer, for instance).

There's also a ton of convention/process taught on top of it for some reason that's IMO not that great, and makes it really hard to see what's actually part of Redux and what's cruft on top of it that you can skip/modify. Redux-as-typically-presented is mostly you doing stuff to follow a (kinda painful) pattern, not the Redux library helping you do stuff.

[EDIT] I'd add that the communication pattern of the docs and various attempts to help people understand Redux seems to largely be "oh, you didn't get it? Let me say the same thing again but louder". Which is why there's SO MUCH documentation and chatter for something fairly simple, I think. Which just compounds the problem.

[acemarke]

A lot of the naming of stuff goes back to Redux's Flux heritage. The Flux architecture labeled those objects as "actions", so Redux (since it was intended as a "Flux implementation") kept that naming.

You are right that the majority of usage is really at the user level, than the library level. I'm actually working on a blog post that will try to clarify and discuss what actual technical limitations Redux requires of you, vs how you are _encouraged_ to use Redux, vs how it's _possible_ to use Redux. Been busy with other stuff, but hoping to make progress on that post this week. If you're interested, keep an eye on my blog at http://blog.isquaredsoftware.com .

If you have concerns with the docs, I'd appreciate any specific suggestions or ideas you might have for improving them. Docs issues and PRs are absolutely welcome, from you or anyone else who wants to help improve them.

Finally, I recently opened up an issue to discuss possible future improvements and "ease-of-use" layers that could be built on top of the Redux core: https://github.com/reactjs/redux/issues/2295 . Would be happy for any feedback you could offer.

(edit: just noted I replied to you a couple different times in this thread, and repeated myself a bit. Offer of discussion absolutely still stands :) )

[badthingfactory]

This is my experience as well. The largest struggle I have with Redux is understanding where things belong. Where do ajax calls go? Should I use redux-thunk? That feels like an anti-pattern to me. Redux-saga is interesting, but it's going to be really tough for unfamiliar devs to understand generators with infinite loops. I also don't feel like writing an infinite loop every time I want to perform a simple fetch. With mobx, shared code goes in a class, it doesn't matter if it's async or not, and observable properties get a decorator.

[acemarke]

Dan wrote a couple great answers on SO that discuss why async behavior in Redux is normally done via middleware such as `redux-thunk` and `redux-saga` - see http://stackoverflow.com/a/35415559/62937 and http://stackoverflow.com/a/34599594/62937 .

As a short version: you _can_ put your async logic right into components, but it's nicer to move that logic outside components for reusability. Middleware have access to `dispatch` and `getState`, so they act as a loophole that enables you to perform async work and then interact with the store.

My own take is that `redux-thunk` is sort of the "bare minimum" approach to async behavior, as it allows you to do stuff with promises and async functions, or complex synchronous logic. Sagas are useful for complex async workflows, and there's also some popular observable-based side effects addons as well. Ultimately, the approach you use is up to you.

If you'd like more info on what good Redux code structure looks like, you may want to read through the "Redux Architecture" and "Redux Techniques" section of my React/Redux links list at https://github.com/markerikson/react-redux-links/blob/master... . Also happy to answer any questions you might have.