McFly – Flux Architecture Made Easy

Re:McFly – Flux Architecture Made Easy by megaman821 on Wednesday November 05, 2014 @12:22PM (#8562894)

Question about the Flux pattern in general, why is a dispatcher/store more desirable than an observable model? The biggest difference I see is a component can add or delete an object with no knowledge of a store just the global dispatcher, but why not just have a static method on a traditional model for adding and deleting?

[ Parent | on HN ]

Re:McFly – Flux Architecture Made Easy by thekenwheeler on Wednesday November 05, 2014 @12:25PM (#8562914)

I think the biggest difference is that Stores don't necessarily contain just one object. They are state containers, so where with a Model you would have singular object based static methods, in a Store you could have methods to manipulate or return any of the objects it contains.

[ Parent | on HN ]

Re:McFly – Flux Architecture Made Easy by megaman821 on Wednesday November 05, 2014 @01:08PM (#8563200)

Fair enough, but why coordinate Store actions through a Dispatcher? Is there much to gain over just calling a method on the Store?

[ Parent | on HN ]

Re:McFly – Flux Architecture Made Easy by lfischer on Wednesday November 05, 2014 @02:50PM (#8563860)

For me, the gain is that you can track all interactions in a single spot. If stores trigger updates on each other, you end up with a web of dependencies that take a long time to trace through when making changes or debugging.

[ Parent | on HN ]

Re:McFly – Flux Architecture Made Easy by thekenwheeler on Wednesday November 05, 2014 @01:11PM (#8563214)

The Dispatcher is helpful because, using the waitFor method, you can marshall the callbacks to enforce an explicit update order in the event that there are dependencies.

[ Parent | on HN ]