mib32 · February 19, 2018 13:32
diff --git a/gistfile1.txt b/gistfile1.txt
 We use the Flux pattern, meaning triggering actions and reacting to state changes is done in a certain way. Calling the API and using a promise in the component isn't Flux. Your code here I'm sure works, however in a web app like ours we can quickly run into problems if we don't follow this Flux pattern.

 For example, it's common that multiple different actions happen at once. Separate components may also be interested in the the result of an action and want to react to a state change. One or more actions may error.

 In the jQuery/promises world web apps like ours quickly ended up in callback hell with messy chains of API calls and updates/errors. Functions got really large too. Flux is an architecture that helps us avoid that as long as we stick to some rules like:

 components render store state and call actions (nothing else)
 actions make API calls and update the store with the result (state)
 components listen to the store and react to state changes
 This lets us keep components, actions and stores small and simple. Multiple components can listen to the same store and call actions on the store whenever they want while keeping those components completely separate.
	We use the Flux pattern, meaning triggering actions and reacting to state changes is done in a certain way. Calling the API and using a promise in the component isn't Flux. Your code here I'm sure works, however in a web app like ours we can quickly run into problems if we don't follow this Flux pattern.

	For example, it's common that multiple different actions happen at once. Separate components may also be interested in the the result of an action and want to react to a state change. One or more actions may error.

	In the jQuery/promises world web apps like ours quickly ended up in callback hell with messy chains of API calls and updates/errors. Functions got really large too. Flux is an architecture that helps us avoid that as long as we stick to some rules like:

	components render store state and call actions (nothing else)
	actions make API calls and update the store with the result (state)
	components listen to the store and react to state changes
	This lets us keep components, actions and stores small and simple. Multiple components can listen to the same store and call actions on the store whenever they want while keeping those components completely separate.