Typed graphql document visitor about gql HOT 9 CLOSED

Thought I'd share a quick update on this - I implemented an alpha version in the execution and schema submodules here. It's partially modeled after graphql/type, but has execution models, and is mainly geared towards enabling intelligent codegen.

Might figure out how to/if we should PR the type definitions into a package here at some point. Not really sure where they fit in the ecosystem - maybe a gql_type module

from gql.

@micimize when you say "type-aware visitor", you want a visitor to traverse selection sets of an operation knowing the type of that selection set? Or is is about something other than selection sets?

from gql.

@klavs that's right, maybe with a way for fragment spreads to access their fragment info as well. For instance, in graphql-to-dart I have to hack fragment fields in order to have them in the spread context

from gql.

I'll need something like that for the new package:gql_code_gen. Maybe I'll be able to extract a reusable visitor. My only concern is that we only have an AST representation of the schema which might not be the best fit for providing the type information. For example, it does not provide easy access to types in a union, and implementors of an interface.

from gql.

am currently working on a more "saturated" schema model abstraction on top of the ast nodes, which should essentially solve this issue. My goal is a graphql schema data model that projects the ast tree into something more "accessible"

from gql.

Great! I managed to live without it, but it's clear that something like that is needed.

from gql.

Nice work there!

Might figure out how to/if we should PR the type definitions into a package here at some point. Not really sure where they fit in the ecosystem - maybe a gql_type module.

I have a feeling that what you've implemented in schema submodule belongs to package:gql, because GraphQLSchema would be useful as an input for the document validator. Interestingly, ExecutableDocument you've implemented in executable submodule kind of does not belong there because it wouldn't be used as an input for any validator.

This is why I went with AST-only validators initially.

Maybe we extend package:gql with:

• package:gql/schema
• package:gql/operation
• package:gql/validation

On the other hand, maybe validation library does not belong to package:gql and it has to move to a separate package next to what is now your schema and execution submodules.

What do you think?

from gql.

I think it's fine to leave them all under gql. To me, gql should encapsulate core typing and soundness features. A good line in the sand would be anything useful at the static analysis phase, and without a runtime or code-generation component

from gql.

Agreed! You're welcome to open a PR with your changes.

from gql.