-
Notifications
You must be signed in to change notification settings - Fork 2k
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
polish: a few smaller refactors #3756
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
70d4963
to
4af125d
Compare
7442471
to
24ce84d
Compare
to improve readability
addError calls locatedError and then adds the error as previously in handleFieldError, throwing if the type is non-null. As opposed to handleFieldError, it does not return null, so as to require the calling function to be more explicit about the new value.
5d17294
to
41f5420
Compare
41f5420
to
86a84ac
Compare
const error = locatedError(rawError, fieldNodes, pathToArray(path)); | ||
const handledError = handleFieldError(error, returnType, errors); | ||
const errors = asyncPayloadRecord?.errors ?? exeContext.errors; | ||
addError(rawError, fieldNodes, returnType, path, errors); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure about this one, especially since addError
throws located error.
But since it's not a public API, let's try and merge it.
Future suggestion: If we convert ExecutionContext into class it can have single method called handleFieldError
that:
locateError
- push error into
errors
filterSubsequentPayloads
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense 👍
@yaacovCR Thank you for extracting it 🙇
Probably makes sense to wait on this until #3815 is approved, which could require a spec change. Filtering is complex! |
refactors 3 and 4 from this were merged in #3878 some of the remaining minor changes from this refactoring PR perhaps could be revisited, but I am closing this stale PR for now. |
completeAsyncIteratorValue
to better reflect what might throw.next()
callshandleError
helper withaddError
with the new function also callinglocatedError
handleRawError
helper which also includes filtering of async payloadsextracted from #3754