Shared vocabulary about how to manage data and data that changes in React. 

He realised that the solutions created himself were in fact each time very close to Flux, so he decided to just do Flux.

1. React Views: the UI, like a button (delete user)
   
2. User Interaction: the button being clicked (​onClick) 
   
3. Action Creators: the click event will call a function (eg. ​deleteUser​)
   
4. Web API Utils: calls another function that knows how to talk to a server
   
5. Web API: the server API (that deletes the user on the server)
   
6. Web API Utils: the JS promise or whatever returns
7. Action Creators: creates a new action (user was deleted) and sends some information about it
8. Actions: 
9. Dispatcher: the action goes to the dispatcher
10. Store: the stores are registered with the dispatcher so the dispatcher calls the stores. "Every single message that the dispatcher sends goes through every single store". The store can look at what the action was, request information about it, decide if it wants to act on this information. The store keeps an internal state of the data it uses (e.g. the users info). 
11. Change Events + Store Queries: The store changes it's data and notifies the App. 
12. React Views: the views are subscribed to stores and update.

Ryan says that sometimes this whole circle can live inside a component. Don't be afraid to start your app this way i.e. do a whole lot of stuff in your component. It's fast, productive. Then you when things start to get complicated, you can move your state (data) up a level. And iterate this way and creating new levels.

Flux, on the other hand says that you should move everything (data handling, server communication, etc.) to the side.