Closed hourliert closed 5 years ago
Any update @hourliert ? The pull seems like is ready ^^ Is a pretty handy feature :D
Hi @WolfDan,
Thanks for your comment. The PR is ready but is partially working. It doesn't work with deeply nested fragments.
I have almost finished a big refactor that makes everything work perfectly. I just need some time to finish.
I have spent the last 5 weeks to do a lot of job interviews and I am planning to move to London in 7 weeks. I will have more time from now since I have found my next job last Friday! 🥇
I will keep this PR updated ;)
Oh good luck with your new job @hourliert !
I'm looking forward for this PR :D
Curious about the movement on this!
Looking forward to this feature making it in (even if it stills need tweaking).
Is this something you're no longer working on @hourliert?
Hi there,
I am not working on this anymore and I feel this PR is old and not well designed to solve the initial problem.
I think we should retrieve the GQL schema (thanks to GraphQL introspection) when the generator starts and build dart classes from that and *.gql
files.
I would be more than happy if someone want to fork and create a PR for that. I am still very active on Github but not on this project (at the moment).
I may work on this again later but I can't give you an estimate date :/.
Many thanks for your comments!!!
Dang, that sucks :/ thanks for the update tho! I've been doing some updates like updating some of the dependencies and what not. Just trying to understand everything, but I am definitely hoping to get the generator working! 😄
Interested in learning what I can help do to bring this PR into fruition.
I have a working GraphQL parser written (that supports deeply nested fragments, etc.), as well as other server-side components: https://github.com/angel-dart/graphql/tree/master/graphql_parser
Hey @thosakwe Thanks for reaching out. This PR is quite old and unmaintained.
I think a good approach would be to simply pass an url of the GQL server to the transformer in the pubspec file, then fetching the the schema, parsing it with your parser so you can know which type is a collection or not. Then when the builder is executed to do the code generation from a file.gql into dart, it should relies on the data it found from the first step to "smartly" generate dart code.
I wish I could give it another try soon but I am currently working hard for my company. I hope this will get better end of august so I can find some time during the weekend working on this project.
If you want to help, feel free to create PRs, I am still very active and github and can create new version of this package if needed.
Hi all, I just cleaning up this branch, and frankly have to clue how to proceed. @hourliert could you provide me some instruction/README/example/test case so I can understand the current logic. Moreover, moving to Dart 2, there are lots of changes when it comes to code generation (see https://github.com/dart-lang/build/blob/master/docs/transforming_code.md) . I'd appreciate any comment or guidance to continue working on this.
cc @thosakwe
I am going to close this PR as I am not working on it at all.
The high-level idea/requirement is:
.gql
fileThis behaviour is simliar to what happen with Apollo client for iOS (swift): https://www.apollographql.com/docs/ios/
It is probably to start from scratch (and inspire yourself) from this PR rather than rebasing it. As you said: it doesn't support dart 2, and I think it still uses dart transformers (which is not the blessed way of writting tasks and watchers).