-
-
Notifications
You must be signed in to change notification settings - Fork 565
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
Polymorphic input types #619
Comments
This implementation would be very useful for API Platform (related issues: api-platform/core#1964, api-platform/core#3258). |
We'll add it but it has to become a part of the spec first and implemented in the reference implementation (graphql-js). |
It's worth noting that since this issue was created, the RFC has gone on a complete tangent from the original "accepted" solution. Instead of introducing a new directive called In my projects I've decided to embrace the |
The current rfc i could find on this is graphql/graphql-spec#825 which moves back to a directive approach using |
@zimzat did you make a custom directive of |
@Roensby The implementation was limited to the directive declaration and a helper method to validate. I didn't build it into the library as an input validation rule because we only had half a dozen places it was used. directive @oneOf on INPUT_OBJECT private function validateOneOf(array $args): void
{
if (count($args) !== 1) {
throw new RequestError('@oneOf requires only one property to be set');
}
} |
ICYMI this got merged into graphql-js three weeks ago graphql/graphql-js#3513 |
I am not planning to work on this myself just now, but will happily accept pull requests that implement |
Hi there, Is anyone planed to work on this feature? Regards |
I'd like to go ahead and present this RFC for implementation, possibly early as it looks to have full support. Or, at the least, I'd like to get the discussion and ideas flowing for implementation in the future.
https://github.com/graphql/graphql-spec/blob/master/rfcs/InputUnion.md
This is particularly of interest in cases where you have an update mutation that has optional relational inputs. In this case, you have to support creating and updating for the relation. It's also the case for one:many relationships, if you wish to update relations within a parent mutation.
There are a number of other use cases that are also important. The above use case is one that we're finding to be very common and a continual frustration point with the API/schema.
The text was updated successfully, but these errors were encountered: