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.
Web APIs API Helpers Actions Dispatcher Stores CoMPoNEnTS User interface IN (from Stores) Change events Model data OUT (to Actions) Calls w/ UI data Components
Web APIs API Helpers Dispatcher Stores AcTIoNS What the app can *do* IN (from Components) Calls w/ UI data OUT (to API Helpers) Data to persist Components Actions
Web APIs API Helpers Actions Dispatcher Stores ApI HeLPeRS API data access layer IN (from Actions) Data to persist OUT (to Web API) Network requests Components
Web APIs API Helpers Actions Dispatcher Stores ApI HeLPeRS API data access layer IN (from Web APIs) Network responses OUT (to Actions) Data from APIs Components
Web APIs API Helpers Dispatcher Stores AcTIoNS What the app can *do* IN (from API Helpers) Data from APIs OUT (to Dispatcher) Wrapped action payloads Components Actions
Web APIs API Helpers Dispatcher Stores AcTIoNS What the app can *do* Components Actions • Wrapped action payload makes all dispatched methods consistent
Web APIs API Helpers Actions Stores DiSPaTChER Global message broker IN (from Actions) Wrapped action payloads OUT (to Stores) Wrapped action payloads Components Dispatcher
Web APIs API Helpers Actions Dispatcher StOReS Holds domain model data on the client IN (from Dispatcher) Wrapped action payloads OUT (to Components) Change events Model data Components Stores
Web APIs API Helpers Actions Dispatcher StOReS Holds domain model 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
Web APIs API Helpers Actions Dispatcher StOReS “When should I 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
Web APIs API Helpers Actions Dispatcher Stores CoMPoNEnTS User interface IN (from Stores) Change events Model data OUT (to Actions) Calls w/ UI data Components
Web APIs API Helpers Actions Dispatcher RoUTeR Matches URL changes to code IN (from URL) Requested application state OUT (to Components) URL state Stores Components Router OUT (to Actions) URL state
AcTIoNS - Sometimes seems like a superfluous layer - Has 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)
StOReS - Sync methods are awesome — can assume the 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
CoMPlEXiTY - There are many parts. Some of the simplicity/ 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
DaTA FlOW - Generally feels like single direction. Once the data is signaled to be available in view, it’s consistent - Still sometimes a challenge to follow the data previous to that
EvENtS - Harder to follow source of actions/data and know 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
ApPRoACh - Experiment with `isCreated` flags. Feels clunky - Remove 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
LeARnINg CuRVe - More full-featured, real-world examples continue to be made - Feels like Backbone days — figure out how Flux works well for you - Relay/GraphQL are incoming
OtHEr FlUX LiBS - Fluxxor - Reflux - Delorean - Fluxxy - marty.js - Fluxible - …check HN Generally clean up some boilerplate, abstract a few things behind a smoother interface