I think this is more of a documentation issue. Redux itself is simple, it's just the barrage of functions you need to use to get anything going that get in the way IMHO. A little layer on top would make it pretty nice in that sense.

Redux effects and friends are simple too but suffer the same issue, they're so functional that they can be hard to reason about. You really need higher level abstractions to hide that stuff or it gets unwieldy fast.

I think it's the typical 80/20 – hard things are easy with React/Redux, easy things are sometimes hard.

I found it to be quite like the other way around. I thought React is a quite decent view library (with medium complexity, if you try to understand and use all the lifecycle methods and think about suitable keys for reconciliation), but I found Redux a bit too primitive for my taste and decided against using it. Reasons where that I don't think storing all state in a single object is a good design idea and that state for me is not only about serializable objects (e.g. I often need to keep promises and other stuff around). I understand that it enables some things like hot reloading and time travel debugging, but thats not the highest priority on my nice-to-have list.

After experimenting with React I'm now using angular2 for my project and apart from some bugs that are left I'm quite happy with it. Architecture-wise I put all state (serializable or not) in multiple-independent plain JS service objects which are injected into the view components through ng2 dependency injection. And they expose their state through observables, which together with things like async pipes makes reactivity really easy.

I might be misunderstanding you, but if you mean handling state at run-time, I feel like handling it in multiple places would be more complex, no? Otherwise, you can actually define state handlers (or as redux calls it, reducers) in multiple files as well, so that each subsection of state is being handled independently.

Nope

NG2 services are essentially just singletons that can be injected into any component.

You can specify a server as an application wide provider (ie attach during bootstrap) or a component-specific provider.

Once a service is injected into a component all you have to do is set subscribe a variable to the service's observable. It the variable is bound to the view, it should update automatically. Event handling can be setup to update the observable by calling .next().

NG2 uses Rxjs (Reactive Extensions for JS) which is just the observable structures plus a ton of functional extensions (ie equivalent to reducers) that can add all sorts of inline transforms. Ex flatMap, filter, debounce, etc.

The Rxjs observable API is almost identical to promises. Except you call .subscribe() instead of .then() and the subscription can be disposed of at any time (ie promises always run to completion).

Rxjs uses hot and cold observables. For cold, subscriptions each have their own independent state and disposing of the subscription will stop the observer from retrieving further updates. Hot observables publish updates to all observers and keep updating even when there are no subscribers. Basically, cold observables are like 'on demand' viewing whereas hot is like watching a 'live stream'.

Not sure if you've looked at Cycle Drivers, they are essentially services or plugins for side-effects. You manage them through sources and sinks and utilize them where every you like, as they run through dataflow components, very powerful and clean.

See http://cycle.js.org/drivers.html

How do you find Redux complex? I found I got the gist of Redux in a few minutes, and was very productive with it a couple hours. I find it much simpler than flux. What do you not like about it?

Glancing at the documentation, it seems to be essentially an implementation of the Memento Pattern, as described in the Gang of Four's book. I have to agree, it's fairly straightforward.

I have not used flux. It's not difficult to understand Redux, but the setup is not simple. Defining the constants, defining the actions, then defining the reducers. It's a lot of moving parts. Throw in the connection to react via react-redux, and it feels like you've had to repeat yourself in several places, not exactly, but enough to be annoying.

I actually find it to be the opposite. Developing with Redux, you can actually throw away most of React's API. In my app, React basically acts like a functionally pure rendering layer.

It definitely has a learning curve, but the very simple data flow makes it pretty straightforward, once you've learned what each layer does.

That's definitely the Redux dream I'm trying to achieve, but as I mentioned in a comment elsewhere, it feels like there is a lot of initial setup. And with each new container, the setup process just starts over. I haven't craved TypeScript in awhile, but for whatever reason, Redux has rekindled the desire (and I know it can be done, I just haven't gotten around to it).

Likely because the stateful portion of any system is going the be the complex part.