Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pkreipke opened this issue Jun 22, 2022 · 1 comment
Assignees
Milestone

Comments

@pkreipke
Copy link

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
Copy link
Collaborator

Benz19 commented Nov 4, 2022

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

@jesse-savary jesse-savary added this to the v0.18.0 milestone Nov 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Community Renovation
Awaiting triage
Development

No branches or pull requests

3 participants