With architectural patterns, the tendency is to make things easier by veiling them behind abstractions that grow more elaborate with time. Eventually, more and more of the system's data changes automatically and developer convenience is superseded by hidden complexity.
This is a real scalability issue, and Flux handles it by favoring explicit actions and data transformations over implicit abstractions. In this section, we'll explore the benefits of explicitness along with the trade-offs to be made.
We've seen already, in this chapter, how difficult it can be to deal with hidden state changes that hide behind abstractions. They help us avoid writing code, but they also hurt by making it difficult to comprehend an entire work-flow when we come back and look at the code later. With Flux, state is kept in a store, and the store is responsible for changing its own state. What's nice about this is that when we want to inquire about how a given...