This chapter introduced you to immutability—both in the general sense of the term and from a Flux architecture viewpoint. We began the chapter with a discussion on the various ways that mutable data can break Flux. In particular, this breaks the crown jewel of any Flux architecture—unidirectional data-flow. Next, we looked at the different types of data-flow that emerge when we start mutating data outside of stores, as these are good things to look for when troubleshooting Flux architectures.
There are several ways that our code can enforce immutable data in our Flux stores, and we explored many of them. Immutable data comes at a cost—because the garbage collector constantly needs to run, blocking other JavaScript code from running, to collect all these extra copies of objects. We looked at how to minimize these extra memory allocations and how to offset the overall cost of using immutable data.
We closed the chapter by implementing several stores that used Immutable.js data structures...