I’ve been doing a bit of a deep dive in React (and Backbone, but that’s for another day). One of the things with React that has looked intimidating from the outside is Flux.
What is Flux?
Simply put, Flux is an application architecture that encourages you to be modular in your code. Facebook doesn’t consider it a formal framework, but rather a pattern for building your webapp.
When using Flux, you want to abstract away any application logic that your React Components are dealing with, and store them elsewhere for modularity.
Here’s a simple diagram showing how Flux’s architecture works:
Let’s talk about these one by one.
Your React Components will fire off specific Actions. Your Actions don’t actually contain much logic within them — instead, they’re going to communicate with your Dispatcher (more on that in just a moment) and provide it with information as to what type of Action your Component is firing.
Your Dispatcher manages this entire Flux process. There is only one Dispatcher in a Flux application, and it receives all Actions being fired and gets to handle them. It passes information over to your Stores, which handle all of your logic.
Stores contain your application’s StateYour Stores will register with the Dispatcher exactly which Actions it is listening for. When those Actions occur, the Dispatcher sends a payload with that Action out to any Stores that are registered to listen for that specific Action. The Stores then respond accordingly, and may or may not update the view depending on its logic.
Your Views are a visual representation of your React app that users can interact with. Your React Components are your Views — they should not contain any app logic outside of firing off Actions for the rest of your architecture to handle.