Flux design pattern - ambiguity about view concept

Question

After reading many explanation about flux design pattern 1, I quite understood how it work.

The dispatcher is a lot like JINI 2 lookup service. And the advantage is clear, the dispatcher doesnt need to know how to perform action and who will perform it. It give you the flexibility to add any store at any time in a continuous integration.

The store is a straight encapsulation of the model and business logic. No problem here, it just have to notify itself to the dispatcher and he will receive action and payload, executing action if supported.

The view is a simple interpretation on data in the store. But the way to notify it, the callback require the view to know who is the store and were it is. Furthermost, the application need to who the view is and were to get it.

In my understanding, the view break the scalability, because while you dont need to know were the action go, you need to know were the result is and the view need to know were the store is. Unless we use another kind of dispatcher between view and store and between client and view.

Answer 1

You're technically correct, although I haven't found this to be a pain point in real-world flux applications. Part of the reason is that only so-called "controller-views" will access the flux stores, and they are solely responsible for taking data in terms of the flux stores and transforming it into data passed as properties to other components.

For example, in Fluxxor's "What is Flux" page that you linked to, there's this image:

In an app like this, only the very top "View" box (the one with arrows from the Stores; perhaps it should be labelled "Controller-View" instead) actually knows about the stores and accesses the data from them; the other views below it get the data via props (and often the data is first transformed by the controller-view based on the propTypes of its children).

[Edit: in modern flux applications, these are commonly referred to as "containers" and do nothing but bridge a normal component and flux stores/actions via props.]

If you're not a fan of this approach, it would be trivial to introduce a new concept between the stores and the views that takes the store data and transforms it somehow, that way none of the views need to know about the stores (though this is essentially what a controller-view does). I also really like the idea of composing views to link them to stores; see this Fluxxor issue for an example.