Here I present how I organize the elements of the Flux architecture in my mind, show how some of my Flux code has turned out, and make some observations of what I see as the good and bad of Flux. Where we're going, we don't need roads.
data on the client Components • Listens for only dispatched payloads it cares about • Can defer payload handling by waiting for other stores • Cohesive around a domain • Can have multiple Stores
make another store?” Components Stores If you discover that there are actually multiple, non- overlapping domains within that store, you have a good case for breaking it into separate stores. - Bill Fisher
value in consistency - Helps with Law of Demeter - Nice translation from method calls (good in views) to dispatch calls (knowledge of dispatchers and action types)
data is there — makes view usage of stores clean - `waitFor` is helpful — great for dependent data in separate logical stores - Love not having setters on Store and letting data mutation flow through dispatcher callback
beauty of the React component abstraction is diminished in the fray - Lots of code in multiple files — mostly declarative, ok to reason about by itself, harder to see connections
what’s affected - Requires consistency in a pattern - Multiple event sets to track 1) Stores register callbacks for dispatcher calls 2) Views register as listeners to store events
metadata (eg, paging) from Stores; Actions won’t need to talk to Stores - Some of my own abstractions for Actions and Stores - Play with some of the Flux implementations How I might experiment with my