feat: support variable arguments in @requires field sets#3448
Conversation
|
adeb738 to
b0fbb3b
Compare
🦋 Changeset detectedLatest commit: 02481f1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 7 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
0402698 to
9afb650
Compare
`@requires(fields: "...")` previously only accepted static literal argument values for required fields that take arguments — there was no way to pass a per-request value (e.g. an end user's currency) through to the subgraph that owns the required field. This adds support for referencing the annotated field's own arguments as bare `$arg` variables, e.g.: ``` localizedPrice(currency: Currency!): Money @requires(fields: "price(currency: $currency)") ``` A @requires field set may now reference one of the annotated field's own arguments as a variable. At query planning time, the value the operation supplies for that argument is threaded into the subgraph that owns the required field: an operation variable is forwarded, a literal is inlined, and an omitted argument resolves to its schema default or null. Variables are kept symbolic through parsing, composition, and query-graph building, and are only bound to concrete values during query planning. Composition rejects unbound variables, type-incompatible bindings, and any variable used in a @provides field set.
9afb650 to
02481f1
Compare
1 participant
@requires(fields: "...")previously only accepted static literal argument values for required fields that take arguments — there was no way to pass a per-request value (e.g. an end user's currency) through to the subgraph that owns the required field. This adds support for referencing the annotated field's own arguments as bare$argvariables, e.g.:A @requires field set may now reference one of the annotated field's own arguments as a variable. At query planning time, the value the operation supplies for that argument is threaded into the subgraph that owns the required field: an operation variable is forwarded, a literal is inlined, and an omitted argument resolves to its schema default or null.
Variables are kept symbolic through parsing, composition, and query-graph building, and are only bound to concrete values during query planning. Composition rejects unbound variables, type-incompatible bindings, and any variable used in a @provides field set.
Fixes: apollographql/router#9583
Mirrors: apollographql/router#9604
Relates to:
Note:
👋 Hi folks. I've done my best here to make sure these changes are accurate and reasonable. I'm obviously not an expert in this codebase - I've tried to adopt the style of surrounding code and consider maintainability in my implementation. That said I'm sure folks closer to the codebase will have opinions here. I'm glad to make any updates you see fit, even if it's heading back to the drawing board to approach this from a different angle.