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?

Answer 1

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

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

1. If you're not sure whether a piece of state belongs to a flux store, then it's most likely that it doesn't.
2. 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.

Answer 2

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

Answer 3

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.

Answer 4

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.