Replies: 3 comments
-
Hi @RXminuS ! The idea of using mappers sounds very good, and I think it will simplify the way you use it. Also, I think the approach of generating one file (when possible) is better and makes generation easier (mostly because circular dependencies). We can help you write this plugin, it sounds super interesting :) |
Beta Was this translation helpful? Give feedback.
-
@RXminuS is there an open PR related to this? |
Beta Was this translation helpful? Give feedback.
-
No not yet, I tried to play around with the code-generator base but haven't had the headspace to properly grasp it yet. But if there's someone more familiar with this codebase I would love to collaborate on a PR? |
Beta Was this translation helpful? Give feedback.
-
I've been a collaborator on the mst-gql project and recently started working on a complete overhaul of the template generator. I find myself drawing more and more inspiration from this project...to the point where I'm not quite sure why we even bother having a separate project at all.
Just for a bit of context mst-gql is a layer on top of the popular mobx/mst (mobx-state-tree) library. MST can handle a lot of the complex graph lookups etc out of the box making it an absolute joy to work with and a lot more light-weight compared to something like Apollo. Additionally, since it's all just models you can extend them with your own functionality keeping all your business logic central. And because it's based on Mobx it's also very portable between frontend frameworks.
I'm happy to contribute personally or make a sizable donation (a few thousand dollars) to help fund this extension given that I believe would really benefit the community at large having a solid option other than Apollo.
Ideally, me or someone on our team could bring some of our mst experience and work with someone with the graphql-code-generator experience to help put this come together quickly. Would love some feedback on a typical timeline.
There's a few things I've thought about:
Single File + Configurable Imports
Right now the mst-gql project generates a bunch of
BaseModels
and then extraModels
files for you to extend. Looking something like thisThe problem with this approach is that
That's why I wanted to stick more with the approach of
typescript-resolvers
plugin where you can specify mappers...in our case "Extensions". That way we would only generate a singlestore.ts
file with all the models (no more circular import hell) and importing all the extensions and applying them to the appropriate models.Working Baseline
The mst-gql project is a working baseline but I don't think this needs to be 1-on-1 compatible with the generated code. In particular I don't think we need a separate project import at all as we could easily generate all of the base-model code in this generator (and the only dependency would be Mobx-State-Tree). That way the code is completely isolated and if we update the generator there are no incompatible changes
Typing
Typing, and in particular w.r.t. circular fields is SUPER important. This has been the primary complaint and one of the reasons I started looking at alternative options.
Query Generators
The projects currently also generates query generators but I'm thinking we should almost (and maybe it has already) split that out into a separate code-generator. It is very pleasant to work with although it can get very verbose.
Beta Was this translation helpful? Give feedback.
All reactions