Without `roots` in config/args not getting protection against circular references...

[pkreipke]

First, not sure this is actually an issue and not just a help question but I haven't found a forum for questions. Please let me know if there's a better forum (Discord, Slack, GH Discussions) etc.

I've been using mobx-state-tree for our in-app state and models and I like it a lot. We're switching from REST to GraphQL on the back end and I've managed to get mst-gql to scaffold models and classes from our GQL server. My first query worked well and adding a mutation was smooth so I'm excited to continue!

I do wonder about a few things:

1. if I remove my objects from roots I end up losing the protections agains circular references - which on the whole seem like a good idea!

2. Why remove them? Because in my existing MST model I thought I was following MST best practices by creating a model for each object or atom and a model for any collection of objects. As a simplified example for a simulation...:

• AssetModel: all about a security e.g. stock

  • props: symbol, name, closing price, quantity,
  • views: total value
  • actions: setters, get stats relative to price on an earlier date

• AssetStoreModel: collection of securities

  • props: map of securities by symbol
  • views: total portfolio value
  • actions: buy(), sell(), split(), etc etc

... and many more.

However, in the generated mst-gql models I get an array of values in the RootStoreBase if I specify roots in my config.

If I have 3 or 4 object like Asset and AssetStore, in the mst-gql view of the world I think I end up putting all the various *StoreModel's views and actions together in the RootStore object I can customize.

If I do so, it'll get quite populated with functions, I lose useful namespacing for the functions and devs couldn't work quite as easily on the the RootStore file at the same time (minor).

So I'm wondering about solutions:

• could I simply generate with roots but then remove them to solve item 1) above? A diff of two generated folder with and without roots seems to suggest yes.
• could I replace them with my own *StoreModel equivalents as long as I match their semantics?
• should I add my existing stores to the derived RootStore instead and modify them to work on the roots provided objects? I fear that without 'self' access I'll need to do a bunch more work than needed.

Looking for advice.... Per

[Benz19]

HI @pkreipke ...Thank you for patience and support on this project. In an effort to get all the issues cleaned up and organized in a timely manner I'm going to assume the role of community manager and do my best to have outstanding issues, comments, questions dealt with in a timely manner. We have been busy, but are very passionate about this project and plan on seeing it through. Thanks for your understanding