[vmarsy]

> ReSub

> The Skype team initially adopted the Flux principles, but we found it to be cumbersome. It requires the introduction of a bunch of new classes (dispatchers, action creators, and dispatch events), and program flow becomes difficult to follow and debug. Over time, we abandoned Flux and created a simpler model for stores. It leverages a new language feature in TypeScript (annotations) to automatically create subscriptions between components and stores. This eliminates most of the code involved in subscribing and unsubscribing. This pattern, which we refer to as ReSub, is independent of ReactXP, but they work well together.

That's interesting, I wonder how this differ from redux and others

I wonder also how is navigation is handled, is it easy to add react navigation in the mix?

Clicking on Next while on https://microsoft.github.io/reactxp/docs/animations navigates to a 404

[bpicolo]

Totally agree with them on that. I love observable-style code vs the full Flux. Especially when I want a small, self-contained component. Redux in particular sort of asks you to not make your components self-contained, since you've got a single global state store. There are apps where it makes sense, but anything not full-blown-SPA-to-the-max can be really cumbersome with the flux pattern.

I find error-handling to be particularly awkward in the Flux flow. You've got the option of adding in callbacks (goodbye unidirectional data flow) or storing errors in global state which makes tracking down errors properly a right pain. Do you have to generate a nonce for every action that could fail and look for that in errors later? That isn't particularly reactive. Are you making data types polymorphic so they're either the thing I actually want or some error class? That doesn't mesh well with collection objects and is kind of gross in general.

I've had trouble finding/figuring out a clean solution for error handling. The flux patterns I've seen feel lacking with regards to error ergonomics.

[barake]

I was curious too, so: https://github.com/Microsoft/ReSub

Looks similar to rxjs or mobx based state stores.

[doublerebel]

I've very successfully used the observable pattern since backbone/knockout days with Spine, on web, node, and Titanium. It is easy to create reusable components and follow the data flow, regardless of data source or view implementation.

These days I use virtual DOM for performance but the architecture hasn't changed in years. The observable pattern with viewmodels is very efficient.

[rounce]

More like vanilla flux and sugar around `store.subscribe`.

[mpweiher]

> to automatically create subscriptions between components and stores

Looks like someone rediscovered/reinvented dataflow constraints, in a slightly hacky way.

See also: The Siren Call of KVO and (Cocoa) Bindings (http://blog.metaobject.com/2014/03/the-siren-call-of-kvo-and...)

[kabes]

That's also how I perceive flux/redux. It's promise is to make it easier to"reason about your application". But it's basically a glorified event model, which does have some nice properties, but you end up with one function bring scattered throughout your entire application as side effects (which you need anyway, be it as sagas, thunks or whatever). Now as your application grows out becomes really hard to follow the flow and if you dispatch an action, it's not clear what will happen because of this. Am I just not getting it right?

[rlabrecque]

Isn't this basically like mobx with it's observables?

https://mobx.js.org/getting-started.html