Allow fields with arguments in @requires - #2120
Merged
Merged
Conversation
馃懛 Deploy request for apollo-federation-docs pending review.Visit the deploys page to approve it
|
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
pcmanus
force-pushed
the
f1987-requires-arguments
branch
from
August 31, 2022 12:59
0cfcaa3 to
a1a2a60
Compare
clenfest
approved these changes
Sep 13, 2022
added 3 commits
September 13, 2022 11:58
If such field with arguments is used in a @requires, then that @requires must provide a value for any required argument and may provide a value for any non-required one (like in any normal graphQL selection set). Fixes apollographql#1987
pcmanus
force-pushed
the
f1987-requires-arguments
branch
from
September 13, 2022 10:05
a1a2a60 to
ee44520
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR allow the
fieldsargument of a@requiresto require fields that are defined with arguments. If some of those argument are required, then those argument needs to be passed a value in the@requires, while non-required argument can be passed a value but don't have to (and if no value is provided, they will be queried with their default value for the@requires, exactly the same way that they would if they were queried directly).I'll note that this PR maintains the rejection of fields with arguments in
@keyand@provides: we can lift the restriction for those directives later in separate PRs. In particular, that may be subjective, but allowing passing argument in@requiresfeels a bit easier to reason about/understand to me than with@keyand@provides, so it may be worth taking a bit more time to think about the implications of the later ones.For
@requires, the code was mostly working out of the box, so the first commit mainly just 1) remove the validation that was rejecting it and 2) adds test coverage. However, adding it makes it necessary to re-validate the@requirespost-merge to prevent a few corner cases from silently merging but failing later, and that added validation is part of that first commit too (with ample comments).The 2nd commit of this PR is new validation to ensure that we reject the use of aliases in the
fieldsargument of@requires,@providesand@key, and this is because this change made me realised that alias were not rejected but were not working properly (they would silently make a@providesnot work for instance if used). This validation is really more of an oversight and make sense regardless of the rest of this PR, but I think it make sense to include it here because "fields with arguments" is probably the main reason why someone might to use aliases in the first place, and so this ticket makes it more important to be clear that those are not supported. To be clear, we could later add proper support for aliases, but this is probably somewhat involved and, afaict, has never be requested by any user, so not too urgent.