How much state does really belong in the stores?

Question

I was wondering, how much state does really belong into the stores, and not into the components? I've read at some places that really all state should live inside the stores.

Would that include really component specific stuff, like input values (before submitting), input validation, if a modal is open, if something has been clicked etc?

What are the best practices here?

To be honest I dont like that pattern with flux. I've used flux before and I didn't go that deep into the store state. what I did was used flux to give data that was needed from the server / actions and let that give me data. when the store has that data I can set state based off of the stores data. However trivial things like input values, toggle state view for an active class, open or closed modal.. those I let the component manage and not have to go through an action. It makes a ton more sense and is a good pattern — John Ruddell, Apr 27 '16 at 21:08

score 2 · Answer 1 · answered Apr 28 '16 at 19:37

The obvious answer:
Keep component specific state (input value, modal open/ closed, stuff clicked, layout, formatting) inside the component state as much as possible.
And app specific state inside the store. Which includes, but is not limited to, stuff you send back and forth with a server.

That said, there is a lot of grey area here:

are filters applied to a search list component state? Or app state (if you save filters for future visits to the same page)?
are visited links in a global root-menu root-component state or app state?
if you are using optimistic updates, you may have a need to save user input stuff in the store, before and after communication with the server.

Some rules of thumb I use:

State belongs in component if it has the same lifecycle as the component (so if the state does not need to exist before the component mounts, and if it can be forgotten after the component unmounts)
If the state needs to be remembered when closing and reopening app, it is probably best put inside the store (where you do exchanges with server and/or localstorage)
If in doubt, start with state in component only: it keeps state much more localised (to the component) and keeps your code more manageable. At a later stage, you can always move the state to the store.

I think these are great rules you've pointed out. I would add that the state that "needs to be remembered when closing and reopening app" can (not in all cases) also be kept in the URL, and sometimes it's even preferable to keep it there rather than in localStorage. — timetowonder, May 04 '16 at 11:55
Good point. But if that data is in the url, then strictly speaking that data is not state, but has to be passed as props to your react-tree somehow. And strictly speaking: the data is not remembered by/in the app, but has to be saved in the url.. — wintvelt, May 04 '16 at 12:47

score 0 · Answer 2 · answered Apr 28 '16 at 15:53

0

View state specific to a component belongs in that component. App state which concerns many components belongs in a store.

answered Apr 28 '16 at 15:53

J. Mark Stevens

4,911
2
13
18

score 0 · Answer 3 · answered Apr 28 '16 at 16:13

It's debatable. For example redux propose a pattern where ALL state belong in the store. Personally I think it is kind of impractical in many situations. It is very rare when I have any reason to store for example state of the button in the store. But sometimes it can be advantageous. It is definitely easier to test when your whole app is stateless.

score 0 · Accepted Answer · answered May 04 '16 at 11:53

Keeping everything in flux stores may be benefitial for some apps.

So first, you should try to decide whether your app is like this.

If you're not sure whether a piece of state belongs to a flux store, then it's most likely that it doesn't.
You'll know when you need flux. And when you reach that level of understanding of whether such application architecture is appropriate for you, you'll probably know the answer to your initial question as well.

But of course it's nice to have some kind of specific guide, maybe just a mental guide, telling you when to keep state inside the component and when not to.

I'd go with these guides:

Is this state purely UI-related? Then you probably don't need to keep it in the store.

Is this state shared anywhere else outside the component? If not, then don't put it in the store. It's fine inside the component.

Can this state be persisted in the URL? If so, then don't put it in the store; put it in the url! It might be a search query of an input or a currently opened tab.

There may be exceptions to all of these, but in general I believe this to correspond well to the original ideas of a flux app.

P.S. Also I should say that there are a lot of talks saying that you should (may) keep all your UI inside an immutable state tree. That's how redux is introduced to lots of people. I think you should understand that while this is a great concept and it allows you so save/replay any user interactions, it is more often than not unnecessary and it's not what the main idea of Flux is about. And redux itself is a great flux tool that doesn't force you to keep all of the UI state in the stores.

How much state does really belong in the stores?

4 Answers4