-
Notifications
You must be signed in to change notification settings - Fork 2.1k
polish: a few smaller refactors #3756
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
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. |
completeAsyncIteratorValueto better reflect what might throw.next()callshandleErrorhelper withaddErrorwith the new function also callinglocatedErrorhandleRawErrorhelper which also includes filtering of async payloadsextracted from #3754