Flux Architecture

Inactive stores

In the previous section, we explored the idea that we can have a relatively static component infrastructure in our Flux architecture. This isn't something that causes concerns about scalability. Rather, it's the large amounts of data that's held in our stores. In this final section, we'll cover some scenarios in which we have a store with lots of data as its state, and we don't want our application to become memory-bloated.

The first approach involves deleting the data from the store, freeing resources. We can take this approach a step further by adding heuristics to our store logic that determines that nothing has changed and there's no need to touch the DOM by emitting a change event. Finally, we'll talk about some of the side-effects ...