Allow scalar parse* and serialized methods to access context
#3600
Conversation
👷 Deploy request for compassionate-pike-271cb3 pending review.Visit the deploys page to approve it
|
|
Hi @yaacovCR, I'm @github-actions bot happy to help you with this PR 👋 Supported commandsPlease post this commands in separate comments and only one per comment:
|
yaacovCR
added
the
PR: breaking change 💥
yaacovCR
changed the title
parse* and serialized methods to access context
Even when provided, `context` must be optional because: 1. Default values for scalar are parsed when building a schema, outside of the execution context. 2. Default values for scalar are serialized during findBreakingChanges and other schema operations, also be outside of the execution context. BREAKING CHANGES are included for argument lists of several functions to include the optional context parameter: 1. `getVariableValues` 2. `getArgumentValues` 3. `coerceInputValue` 4. `valueFromAST` 5. `astFromValue`
|
Updated the PR with necessary changes to |
There was a problem hiding this comment.
Strongly oppose this.
Scalars are used in many situations that don't have access to context and you made it optional for that reason. Scalars should behave in exact same way no matter where they are used.
Moreover, we deliberately do not pass context in functions like validate that was already discussed and rejected in another issue.
In use case outlined in #3539 that means if you specify scalar as literal you will get not localize error message (through validate) but if you pass it as the variable it became localized.
Same with other situations where scalars used outside of variables, e.g. default values in SDL you will get non-localized values.
I think localization usecase should be solved through error's extensions and formatError function from GraphQL server lib as outlined here: #3539
|
I don't think I am as dogmatic about scalars always behaving exactly--exactly--exactly the same in every context. But, I do think that the solution that @IvanGoncharov has suggested works better in the proposed use case, and so this PR is currently a solution in search of a problem.... or.... more specifically, a use case that justifies the complexity and caveats. Thanks for the review! |
See #3539 for more details.
Even when provided,
contextmust be optional because:BREAKING CHANGES are included for argument lists of several functions to include the optional context parameter:
getVariableValuesgetArgumentValuescoerceInputValuevalueFromASTastFromValue