Consider local state management use-cases

[Kashuab]

For some complex apps that need to stage working data, mobx-depot could lend a hand with its data store. Its ability to resolve and maintain dependencies could've relieved a lot of headache in projects I've worked with in the past.

[Kashuab]

The following approach seems ideal:

1. Create a schema.graphql for the local types
2. Use the generate CLI to generate a root store and models

Questions:

• What if some types intersect with the store that uses remote types?
• Can mobx-depot elegantly handle multiple simultaneous stores?
• What happens if data from the local store is committed, which should then be put into the remote store?

Answers:

• Perhaps generate could handle multiple schemas (I'm really interested in this)
• Not really, since functions from rootStore.ts are named generically, i.e. getRootStore, setGraphQLClient

I think in an ideal scenario there is only one RootStore within a project. The solution here may be to allow generate to accept multiple schemas. However, the big question here is: how would we handle duplicate types? There may be local state that should never make it to the remote API.

[Kashuab]

Not a pre-release issue, but this is still important.