GraphQL Switch

[budde377]

Let's implement a more Relay type builder/client.

Dart Code Analysis

• Look for graphql(...) from package:graphql_switch and generate hooks from that or just from the hook pattern? graphql
• Where do we output generated file? Co-location will ease name collision but complicate imports. One big file
• How do we handle nullable/lists of fragments: Create Hook variants: nullable, list, listNullable? Directive?

class My extends HooksWidget {
  Widget build(ctx) {
    final result = useQuery$MyQuery(
      graphql(const """
        query MyQuery { name }
      """),
    );
    return Text(result?.data.name ?? 'Loading...');
  }
}

final MyFragment$data data = useFragment$MyFragment(
graphql(const """
fragment MyFragment on User { name age }
""")
);

final MyFragmentOptional$data? data = useFragment$MyFragmentOptional(
graphql(const """
fragment MyFragmentOptional on User @switch(optional: true) { 
  name 
  age 
}
""")
);

final List<MyFragmentPlural$data> data = useFragment$MyFragmentPlural(
graphql(const """
fragment MyFragmentPlural on User @switch(plural: true) { 
  name 
  age 
}
""")
);

GraphQL Code Analysis

• Make serializers generally following graphql_codegen with special handling of fragments.
  • Add serializers for fields and concrete types
• Instead of expanding fragments, make serializers implement a $key interface.
• The same holds for other fragments, they shouldn't expand fields of sub-fragments.

Serializers:

"""
query MyQuery {
  ...SomeFragment
  name
}
"""
class MyQuery$data implements SomeFragment$key {
  final String name;
} 

"""
query MyQuery2 {

  interface { 
    name 
    ... on ConcreteType1 { concreteName }
    ... FragmentOnConcreteType1
  }
}
"""

class MyQuery2$data {
  final MyQuery2$interface$data interface;
}

class MyQuery2$interface$data {
  final name;
}

class MyQuery2$interface$$ConcreteType1$data implements FragmentOnConcreteType1$key {
  final concreteName;
} 

Linting

• Enforce naming of operations (and fragments) through linting making it optional.
• Check if fields are used in component and lint.
• Check if operation/fragment name matches used hook.

[baconcheese113]

How do we handle nullable/lists of fragments: Create Hook variants: nullable, list, listNullable? Directive?

Do we need to support these? What's the use-case? Maybe I'm misinterpreting the names but it seems like fragment spreads should be static and List responses should be of type [User]

[budde377]

This is more around the developer experience, think how if you pass a null as the key to a useFragment in relay, you get a null as result, or how you can use @relay(plural: true) to handle a list of fragments.

[baconcheese113]

Ah okay, I never really used them that way but I see now that it lines up with Relay's docs

[baconcheese113]

Hooks

I love Hooks in React and refactored straight to them when they went into v16, but I'm still a bit uneasy about using them in the Dart ecosystem since the Flutter team seems to be doing everything they can to not implement them as-is, but to make some functional change to how they work (so as not to "copy" React) and then introduce them. At least that's the impression I get from the threads spanning 4 years here and here

Not sure I'm ready to refactor to using hooks in my flutter projects, are you planning non-hook functionality as well?

[budde377]

Sure. For a first version, I'd just support one of them to get something out. Since implementing widgets from hooks is trivial, I'd start with that.

[baconcheese113]

Variables for Fragments

I think I briefly looked for a way to pass Input fields through to nested fragments in graphql_codegen and didn't see a way, that would be an awesome addition in Switch. Both @arguments and @argumentDefinitions here

[baconcheese113]

Linting

• Enforce naming of operations (and fragments) through linting making it optional.
• Check if fields are used in component and lint.
• Check if operation/fragment name matches used hook.

This would be so helpful to have! Some ideas:

• All operations PascalCaseFilenameOperation
• Fragments PascalCaseFilename_$key

[budde377]

Sometimes you want to have multiple fragments or operations per widget/file. This can be supported with the rules:

• Operations should start with PascalCaseFilename and end with Operation. This allows for MyQueryFetchPeopleQuery.
• Fragments should start with PascalCaseFilename.

[baconcheese113]

File imports

I wonder if there's any way to include file imports in graphql() just because it makes it so much easier to see and link the source of the fragment. This is a departure from Relay, but something I liked about ApolloClient
Maybe something like

// Parent.dart
class Parent extends HookWidget {
  ...
  @override
  Widget build(BuildContext context) {
     final result = useQuery$ParentQuery(
      graphql(const """
        query ParentQuery { 
          user { 
            ...child_user 
          } 
        }
      """, [Child.fragment]),
    );
    return Child(userFrag: result.data.user);
}

// Child.dart
class Child extends StatelessWidget {
  final Child_user userFrag;
  const Child({Key? key, required this.userFrag}) : super(key: key);

  static final fragment = graphql(r'''
      fragment child_user on User {
        id
        name
        ...child1a_user
        ...child1b_user
        ...child1c_user
      }
    ''', [Child1a.fragment, Child1b.fragment, Child1c.fragment]);

  @override
  Widget build(BuildContext context) {
    print(userFrag.data.id);

Thoughts?

[budde377]

I like the idea of being able to navigate to the right fragment. The only problem I'm seeing is that you now have to keep two things in sync; the fragments in the GraphQL and the reference. I think this library in essence should be as opinionated and simple to use as possible, so this would go a bit against this.

Alternatively, the syntax could be something like:

final fragment = graphql("""
fragment Child on User { name }
""");

final fragment2 = graphql("""
fragment Child2 on User { ...${fragment} }
""");

[baconcheese113]

Ah, any way that I can click into the location of the fragment from where it's spread would be perfect! This really helps when drilling down into what fields the fragment is referencing or when refactoring. If you're saying the syntax would need to be a bit different, then no problem

// parent.dart
final query = graphql('''
query Parent { user { ...${Child.fragment} } }
''');

// child.dart
final fragment = graphql('''
fragment Child_user on User { name }
''');

your graphql function isn't static tho, right?

[budde377]

Cool! I think we should have this as a stretch goal. It'll complicate the analysis a fair amount. Because we now need to statically infer the name of the fragment.

[budde377]

A proof of concept is now available on the feature branch! Check the example folder.

[satvikpendem]

Is this still being worked on or was it just a proof of concept? I really like Relay so wondering if this could be a viable replacement in Dart.

[budde377]

I hope to pick it up again, but I can not provide a timeline.

…

On Thu, Dec 21, 2023 at 1:19 AM Satvik Pendem ***@***.***> wrote: Is this still being worked on or was it just a proof of concept? I really like Relay so wondering if this could be a viable replacement in Dart. — Reply to this email directly, view it on GitHub <#142 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2UFS4EUPCHT76UCMT2AJDYKOFBJAVCNFSM54QD2NF2U5DIOJSWCZC7NNSXTOKENFZWG5LTONUW63SDN5WW2ZLOOQ5TOOJRGM2DSNA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[satvikpendem]

No worries, have a happy holidays!