ardatan/graphql-import

Support nested imports

Closed this issue ยท 11 comments

For the following schema in a.graphql

type Query {
feed: [Post!]!
me: User
}

I'd like to be able to do something like this:
In b.graphql

# import Query.feed from "a.graphql"

and that query automatically gets appended to my other queries in b.graphql

@schickling I think this would be a very valuable addition, also based on recent questions on Apollo Slack by others regarding stitching schemas and needing root query/mutation/subscription fields. Are you okay to move ahead with this?

I'd love to see some more examples for this and explore other syntax options.

@stubailo @freiksenet do you have an opinion about this?

Apart from # import Query.feed from 'a.graphql' (graphql path style) and # import feed from 'a.graphql/Query' (js/ts style) I don't see many other options to define this type of import. Also looking forward at getting more input.

Another alternative (just to have options to choose from) would be inspired by mixins/include syntax from libraries like sass. The '*' in this case would translate to Query.* in b.graphql, because of the position of the import statement. Throwing wildcards in the mix as well, as we are discussing syntax, but that question would also apply to regular 'top-level' imports.

type Query {
    # import * from 'b.graphql'
    # import allPosts from 'c.graphql'
    # import create* from 'd.graphql'
    otherfield: [Post]
}

After thinking a bit about this and seeing more use cases, I like the initially proposed syntax:

# import Query.feed from "a.graphql"

There are two ways this can be implemented:

  1. Using extend type
extend type Query {
  feed: ...
}
  1. Merging all types

Since there isn't final consensus yet around the extend syntax, I suggest to go for (2).
@gaurav107 @kbrandwijk would one of you be open to create a PR for this?

Cases to consider

  • Type (of imported field) doesn't exist yet
  • The imported field already exists on the target type

Another edge case:

  • Root Type doesn't exist yet

Question @schickling:
When you import a type that already exists, what happens now?

When you import a type that already exists, what happens now?

I suggest, it should throw an error.

Is this limited to certain types? I can see this getting out of hand if something like this is allowed:

# import Store.products from "store.graphql"

type Store {
  hours
}

@jlengstorf It's limited to root types (Query, Mutation, Subscription).

What's the final syntax chosen here? I wasn't able to find an example in README.md

My use case is that I want to define queries and mutations in separate queries.graphql and mutations.graphql files. I want to tie them together in a final schema.graphql file.

Found it in the fixtures:

# import Query.* from 'b.graphql'

@marktani Did you get the nesting to work? Was the nested using the prisma.graphql that was generated or only custom? I'm trying to split them apart like you did.