Earlier in the book, I mentioned that stores aren't models from MV* architectures. They're different from a number of perspectives, including their ability to cope with changing schemas in other architectural areas, such as the API and changing feature requirements. In this section, we'll look at the Flux store's ability to adapt to changing APIs. We'll also address the opposite direction of change, when views that consume store data have changing requirements. Finally, we'll talk about other components that might change as the direct result of a store's ongoing evolution.
API data changes, especially during the early stages of development. Even though we tell ourselves that a given API is going to stabilize over time, this rarely works out in practice. Or if an API does become stable and unchanging, we end up having to use a different API. The safe assumption is that this data is going to change, and our stores will need to adapt to such...