Let's first off explain our title. What do we mean by 1.21 Gigawatt? I'm going to quote the character Doc Brown from the movie Back to the Future (http://www.imdb.com/name/nm0000502/?ref_=tt_trv_qu):
Why are we talking about the movie Back to the Future? This is where the name Flux comes from. It's time for another quote from the same movie:
So as you can see, there is an explanation for the name Flux. It obviously allows us to travel in time. At least for Redux, which we will write about later in this book, time travel is possible through something called time-travel debugging. Whether that needs a bolt of lightning is for you to find out dear reader.
Flux is an architectural pattern created by Facebook. It came about as it was perceived that the MVC pattern simply did not scale. It did not scale for large code bases as they tended to become fragile, generally complicated as more and more features were added, and most of all, unpredictable. Now let's hang on that word for a second, unpredictable.
Large systems were thought to become unpredictable due to their bidrectional data flow between models and views when the number of models and views really grew, as depicted in the following diagram:
Here, we can see that the number of models and views is starting to grow. Everything is somewhat under control as long as one model talks to one view and vice versa. This is, however, seldom the case. In the preceding diagram, we see that suddenly a view can talk to more than one model and vice versa, which means we have a cascading effect on the system and we suddenly lose control. Sure, it doesn't look so bad with just one deviating arrow, but imagine that this one is suddenly ten arrows, then we have a real problem on our hands.
It is the very fact that we allow bidrectional data flows to happen that things get complicated and we lose predictability. The medicine or cure for that is thought to be a simpler type of data flow, a unidirectional flow. Now, there are some key players involved in enabling undirectional data flow, which brings us to what this chapter is meant to teach us.
In this chapter, we will learn:
- What an action and an action creator are
- How the dispatcher plays a central role in your application as a hub for messages
- State management with a store
- How to put our knowledge of Flux into practice by coding up a Flux application flow