Comparing to Artemis

[baconcheese113]

Hey! First off thanks for all your effort in both this lib and graphql_flutter....I'd probably go back to React Native without these. I read you were inspired by Relay and I think that's awesome! Relay is probably my favorite client-side graphql development tool, even more so than ApolloClient.

I switched from using graphql_flutter without static types to Artemis a month ago, and unfortunately I'd say it has just about as many cons as pros from my experience so far. Some of these are probably due to Dart limitations in the difficulty of working with json objects when compared to how easy typescript handles them....but still limitations regardless.

I made an Artemis example project to document my findings and put some of the limitations there. I'm getting ready to make a similar example project with graphql_codegen and just wondering if the roadmap includes some features that Relay had and if the same limitations of Artemis exist in graphql_codegen.

Here and here are an example of how I was using graphql with graphql_flutter.

Here and here are an example of how I used graphql with ApolloClient. This is very similar to how I was using with Relay, except at the time I used the fragmentContainer HOC

With Artemis I'm constantly running into name collisions with sub fields defined in different fragments, and just using nested fragments in general. Also moving Queries/Fragments out of the file they're used in has made it harder to refactor code and prevent over-fetching once the variables are no longer used in that file. Here are some of the issues I had with Artemis comigor/artemis#392 and comigor/artemis#394 I'm at the point now where I'm spending 10 minutes adding new functionality and then 20 minutes wrestling with Artemis to generate types correctly for my nested fragments without name-collision errors, and since I have to alias the sub-fields for them to work I'm sometimes fetching 5x more data for the same query without Artemis because each aliased field is resolved separately.

So my questions:

1. Do you have plans to allow Queries/Fragments to be defined in dart files? Can you elaborate about where the challenge is here and how it might be approached?
2. How do you avoid the field name collision problems that Artemis has?
3. Can you pass nested fragments down the widget hierarchy without issues?
4. Do you have plans to allow a dataId to automagically be added to types that contain it (similar to how __typename is), since it's required for cache normalization?

[budde377]

Thanks for reaching out, let me try and answer your questions:

Do you have plans to allow Queries/Fragments to be defined in dart files? Can you elaborate about where the challenge is here and how it might be approached?

I've considered it, it amounts to analyzing the dart files and come up with a way to link the generated queries to the right methods/widgets. It is doable, but will be different than Relay because of the difference between the TS/Flow type system and Darts typesystem. Not unmanageable, but not started.

How do you avoid the field name collision problems that Artemis has?

By a better implementation of how fragments are mapped to serializers. You can read more here.

Can you pass nested fragments down the widget hierarchy without issues?

I'd certainly hope so! A big part of the motivation for writing this library was that I disagreed with how Artemis handled fragments. If you experience any problems here, please open a issue.

Do you have plans to allow a dataId to automagically be added to types that contain it (similar to how __typename is), since it's required for cache normalization?

Certainly sounds doable. Feel free to open an issue.