-
-
Notifications
You must be signed in to change notification settings - Fork 812
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
Feature request: support for composite Input Types #179
Comments
Note: if this isn't crazy, has a chance of being accepted, I'd be happy to look at implementing. Would like to know if it has legs first. |
I don't think we'll accept something that isn't part of the "official" GraphQL schema language at the moment, especially if it can't be parsed with GraphQL.js. I'm not really sure if auto-generating input types is a good idea, because then whenever you add a field to an object type you still need to decide if it also makes sense to add it to the input, and possibly update the method to insert it? One thing that could be interesting is extending the type generation with custom directives. So maybe type IntermediateThing @input {
id: Int!
description: String! @input
}
type CompositeThing @input {
id: Int!
leftThing: IntermediateThing @input
thingStatus: String!
} A few things to keep in mind:
My main issue with this is that it makes it harder for I'm curious, does duplication of these fields cause a maintenance burden, or it's just more to type up front? |
Thanks for the feedback. I'm concerned about both typing up front (though that is actually just cut and paste of most of the body) and maintenance. Also readability of the schema (high noise level due to unnecessary repetition). I will think about a suggestion that would be parseable, and also able to support arguments (which is important) not interfaces or unions (which so far seem to be rarer and acceptable to require all the typing). |
I'm saying that input types literally don't have arguments in GraphQL, so fields will either only be shared if they have no arguments, or perhaps the argument list can just be removed. But then it seems kind of weird to share it.
Same with those - input types can't use interfaces or unions in any of the field types. |
I suspect that this deals with this issue. However, at first look it is rather more heavyweight than a nice solution for this point problem might be. |
Conceptually, every field of a type can be always settable, settable on creation, settable on update and never settable. e.g. email: settable on creation This, unfortuantely, forces you to create the following schema:
Sure, for such a small schema it isn't a big issue. However, you typically have tens of more objects, perhaps even containing other objects, and in practice it gets real complex, real fast - keeping all the types and inputs in sync.
And so forth. I think that using directives is definitely the way to go.
UserSettingsCreate won't be generated (or it can be, but it won't be used anywhere in the schema). Note that this can also be done to a schema prior to passing it forward to -- OpenAPI attempted to solved this issue with Normal property - creation: optional, update: optional, read: optional Having return object schema validation helps for server debugging, and is disabled in production. |
Oh, also. To improve readability, you could also be a bit more explicit:
This is way more readable and less error-prone than the existing copy/paste/modify method. As for typing. There is a bit of parsing here: you'll need to be able to handle multiline field definitions, ignore fields not marked with @update or @create, and replace non-scalars with their It's more like a C preprocessor. :) |
Going to close this since it's something that would have to be added to |
Why would graphql-js need to add this first? |
Any update on this? Have you seen any projects that tried to implement this feature? |
@Jetmate As this isn't supported by graphql-js directly, I have put this on the todo list for my GraphQL Gateway Framework, Qewl, along with a couple of other things on top of the spec, like namespacing and imports. I will update here when it's in. |
@kbrandwijk Thanks! I'd love to see this feature implemented. |
Most of my query types need corresponding input types.
This is a lot of duplication of information to type into a schema.
makeExecutableSchema
could support generation of InputTypes automatically with trivial extension to the input syntax.instead of
We could say
and makeExecutableSchema could provide both the
query
andinput
schema elements that we need.The text was updated successfully, but these errors were encountered: