Summary

This chapter introduced you to the driving principles of Flux. These should be in the back your mind as you work on any Flux architecture. We started the chapter off with a brief retrospective of MV* style architectures that permeate frontend development. Some challenges with this style of architecture include cascading model updates and a lack of data-flow direction. We then looked at the prize concept of Flux—unidirectional data-flow.

Next, we covered how Flux favors explicit actions over implicit abstractions. This makes things easier to comprehend when reading Flux code, because we don't have to go digging around for the root cause of a state change. We also looked at how Flux utilizes architectural layers to visualize how data-flows in one direction through the system.

Finally, we compared application data with state that's generally considered specific to UI elements. Flux stores tend to focus on state that's relevant to the feature it supports, and doesn't distinguish between application data and UI state. Now that we have a handle on the principles that drive Flux architectures, it's time for us to code one. In the next chapter, we'll implement our skeleton Flux architecture, allowing us to focus on information design.