-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type extension does not work #42
Comments
This is a limitation coming from graphql: graphql/graphql-js#922. I believe that extend definitions should be taken into consideration, but there has not been any recent activity on actually making that happen. |
I would like it too, it could be great feature 👍 |
A similar but different use case is extending imported types (like
Does this work? |
No that's the same situation. The |
@IvanGoncharov any idea when this functionality will land? |
Good use case of this could be having many files in project extending |
Right now we can simulate the behavior at least for Query-, Mutation- and Subscription-Type by importing like: # import Query.* from a.graphql
# import Query.* from b.graphql Take a look at the following test cases: |
@schickling As always then somebody implements it 😄 |
Another use case for this would be to extend and add "future" stuff (say, that Prisma is yet to implement like https://github.com/graphcool/prisma/issues/60). Currently, I am copying the original type from |
I need this too. I have managed to work around by just loading .graphql files myself and passing an array of strings to makeExecutableSchema() (and using extend type Query etc. to avoid multiple declaration errors). graphql-tools and graphql seem to handle the type extensions fine. |
I got around this in the following way (though it may be a pain to refactor once in type A {
name: String!
}
type Query { # notice all we have to do is omit 'extend'
AbyName(name: String!): A
} in # import * from 'A.graphql'
# and import the whole thing as above
type Query {
someRootQuery(thing: String!): A
} So this way each file can be modular in that they will contain all their own |
Any news about
If I use |
I think @Grmiade has correctly identified the issue in the last comment. In my use case I am following guides on merging schemas https://www.apollographql.com/docs/graphql-tools/schema-stitching.html. This requires a typeDefs definition that only contains 'extend type' blocks to effectively bridge two schemas. const linkTypeDefs = `extend type FirstSchemaEntity { test: SecondSchemaEntity }` When used in literal form as in the above comment it works. But it doesn't work and errors when the extend typeDefs definition is imported via importSchema, in the below example. const linkTypeDefs = importSchema('./linkTypeDefs.graphql') |
Any update or workaround ? |
This is what I am doing as a workaround.. it really sucks, I wish they would fix this.
|
@mwoelk mentioned:
This is coming from this particular definition of which types are considered "root fields". Here's an idea to ease some of the pain points introduced by trying to do type extension: allow users to modify or extend that // "Viewer" is a custom type
const schema = importSchema('./schema.graphql', { rootFields: ['Viewer'] }); This would be particularly useful in scenarios like Relay's # foo.graphql
type Foo implements Node { ... }
type Viewer {
fooQuery(id: ID!): Foo!
} # bar.graphql
type Bar implements Node { ... }
type Viewer {
barQuery(id: ID!): Bar!
} # relay.graphql
type Query {
viewer: Viewer!
node(id: ID!): Node
}
interface Node {
id: ID!
}
type Viewer {
id: ID!
} And the root ( # import Query.*, Viewer.* from "./relay.graphql"
# import Viewer.* from "./bar.graphql"
# import Viewer.* from "./foo.graphql" Which would produce the following final SDL: interface Node {
id: ID!
}
type Bar implements Node { ...}
type Foo implements Node { ...}
type Query {
viewer: Viewer!
node(id: ID!): Node
}
type Viewer {
id: ID!
barQuery(id: ID!): Bar!
fooQuery(id: ID!): Foo!
} What do you think? I could put together a simple PR for this, if you are up to. |
I am doing a weird hack for experiment, const server = new GraphQLServer({
typeDefs: [
"src/generated/prisma.graphql",
fs.readFileSync("./src/schema.graphql", "utf-8")
],
resolvers,
context: {
prisma
}
}); schema.graphql extend type Query {
feed: [Post!]!
drafts: [Post!]!
}
extend type Mutation {
createDraft(title: String!, content: String): Post
publish(id: ID!): Post
} It works as expected, I have all queries and mutations from generated graphql file and the extended queries as well. See below, The problem with this approach is,
So what I was looking for,
It would increase modularity and reduce code duplication is so many levels. Specially I wouldn't have to end up copy pasting the schema in multiple places. |
Hi @pie6k ! Could you install |
@ardatan Hey. I just stumbled onto the problem. Using ^1.0.0-beta.2, I have the following files: type Query {
cities: [City]
} City.graphql type City {
id: ID!
name: String!
}
extend type Query {
getCity(id: ID): City
} Now... the behaviour I'm getting, is that if the extend is in City.graphql, it's not recognized, judging by me dumping the typeDefs in the importSchema() promise. Edit: I'm using apollo-server with express, if that's relevant. |
Available in 1.0.0! |
Assume
main.graphql
User.graphql
In resulting compiled schema Query has only version. There is no
me
field added.The text was updated successfully, but these errors were encountered: