you can think about views: a. UI produced is a function of the data b. The same data input will always produce the same output c. When data changes, React will re-render the UI
developing large applications that allows straightforward reasoning about the data • (Since data drives the UI for React.js, this sounds like a good idea!)
textbox triggers the "triggerSearch" function on the component which executes the TypeAhead fetchResults action b. fetchResults makes an empty dispatcher call (which tells all the stores that the "fetchResults" action ran) c. the TypeAheadStore is listening for the fetchResults action and has a handler set state that a fetch is occurring d. the container component is listening for changes in the store, it then sets its own state, which causes it to re- render showing the loading bar e. Utils/TypeAheadResultsFetcher.fetch makes an ajax call and returns data f. the fetch resolves it's promise and calls the updateResults action with the returned data. g. This returned data is passed through the dispatcher for all stores that might be listening h. The typeAhead store is listening for the updateResults action, it has a handler that sets its own state from the data sent with the dispatcher and also clears the “fetching” state flag i. The typeahead container is listening for typeAheadStore changes. It receives the new state from the store, hiding the loading indicator and passing the results down to the dumb typeAheadResults component j. The typeaheadResults (child) component takes the data and re-renders itself
• Components trigger Actions • Actions send data through the Dispatcher • Stores listen to certain Actions sent with the Dispatcher • Stores set their own state • Components listen to that state and re- render themselves on changes
to a particular layer in the application and establishes a completely predictable way to get data in and out of there. • This is nothing new, it’s called “Command Query Responsibility Segregation”
They are “read only”. They listen to actions and update themselves appropriately • Meaning: no funny business can happen, data from actions is the only way to communicate with a Store. • Easy mental model to follow (and debug!). Less surprises! • A Store is the only place in your whole app that has privilege to mutate the data
I can tell you the exact UI flow and data representation in the application • I can tell you how to get to a particular state in the UI • I can save and replay to get to a specific UI state. WHAT?
and mentally troubling paths. • Observers have no context, you have no idea what triggered the change. • Observers can cause chain reactions of other observers and can fire multiple times. Data driven State-based/UI is better!
separation of concerns (no cheating) • Learning curve is not as steep as other framework-oriented development • Karma+Mocha (QUnit FTL) • React Hot Loader
• I am advocating that based on my experience from using other frameworks, React.js with Flux solves very real (bad) problems in an easy to understand manner. • My spike was an absolute pleasure to create • I recommend future complex JavaScript development in this manner
timtyrrell
utgwkk
kntkymt
naruse
nrslib
kawayu
masuda220
kishida
suikabar
mom0tomo
yusukebe
kajitack
kentaroutakeda
jnunemaker
nikkihalliwell
axbom
marcduiker
rabernat
marktimemedia
inesmontani
hatefulcrawdad
thoeni
reverentgeek
ks91
