CODEWITHSUNDEEP
reactjsreactjs-fluxflux
fox
fox

Reputation: 16496

Flux: when should state be put into a store?

I've been working through the TodoMVC example in Redux and I noticed something interesting: the application hands CRUD of todo objects off to the store, but handles filter state exclusively by passing constants between components, namely the footer and the list view.

What is the rule of thumb here? I appreciate that filter state is likely never going to be saved to persistent storage (except maybe as part of a user profile), but it also feels like keeping filter state out of the store is kind of at odds with the flux philosophy. Why not delegate updating filter state to the store?

Upvotes: 1

Views: 120

Answers (1)

Jeff Fairley
Jeff Fairley

Reputation: 8314

I would say this one comes down to use case + personal preference. In the case of this simple app, filter is shared between two components that have a parent-child relationship, but nowhere else. This is certainly fine in this scenario.

Benefits of State

Smaller Stores

A benefit you would see with a setup like this would be simplified/smaller stores. I'm currently building an application with Reflux, and one of my stores has ballooned quite a bit to where I'm thinking about how it can be broken down or if any data can be removed.

Fewer Attempts to Re-render Components

An added benefit to a smaller store (at least in Reflux) is fewer event dispatches, which probably means fewer DOM renders (or at least fewer virtual DOM recalculations).

(Keeping the caveat of Reflux), the "easy" way to set up listeners to a store lends itself to a component getting re-rendered for a change to any property, even if that component only cares about 1 or 2. Back to my large store issue, it contains around 10 properties at this point. Lots of components are connected to it, and 1 of those 10 properties is fairly volatile. This causes all listener components to go through the virtual DOM more often than is necessary. Consequently, I also have lots of shouldComponentUpdate functions defined where I wouldn't otherwise need them.

Benefits of Store

Influencing DOM Layout

Of course one disadvantage to passing filter as a prop to Footer is how it influences the DOM layout. I.e. Footer must be a child of MainSection. This is enough reason to make me want to put filter into a store, despite the overhead.

Data Unavailable to Other Components

IMO, the most obvious disadvantage is that the filter data is simply not available elsewhere in the application. Depending on your scenario, this could be a plus or minus, but I tend to feel that it's usually a minus.

Upvotes: 2

Related Questions