[hknd]

We used to have that but moved to an approach with multiple "rootStores" per self-contained route (sometimes we have more than 1 root store in such a scenario).

But we also have multiple smaller stores which are not connected to the root store. Think: multiple not-connected trees where each node is a store.

I must agree that both approaches have pros and cons, e.g. passing down data down a long path of stores is annoying.

[shermanmccoy]

In my experience, not specific to front end, managing multiple long life objects can be a headache.

Out of curiosity, how do your 'not connected' stores know when, say, a user logs out?

Also, I suppose you have to write code, bespoke to each object, to be able to reset these objects too?

[cloverich]

(Thinking in terms of local stores)

> how do your 'not connected' stores know when, say, a user logs out?

If they need this information, it can be passed in from above, or pulled from context. But unless the store and component need to stay mounted when user logs out, they might not need to do anything. There's nothing wrong with a local store being created by a component that receives props and provides them via constructor arguments.

> write code, bespoke to each object, to be able to reset these objects too?

I almost never do this, and nearly always create a new store when the component mounts. The combination of `useLocalStore`[1] with mobx-react-lite makes this straight forward. So per the above example, your component could `useLocalObservable(() => new Store(props.user))`

[1]: https://mobx.js.org/react-integration.html

[hknd]

Most of the stores not long-life objects.

The current store holding most of the displayed data stays alive (while not switching to a different route), but everything else resets or gets recreated when needed. (no need to keep stores alive if they are not required or used)

Stores for specific "sub" views (think dialogs, tabs, collapsibles, ...) are getting created/destroyed ad-hoc.

Main Store for a specific view holds the current data (which receives updates via gql subscriptions ~every second), the current filter which is applied to it's children (only show Apple related securities) and currently visible/hidden state of any children.

User/App/Global related attributes which don't change often are stored in a globally available object (and is easy for us as users don't log out or anything)