graphql-js
graphql-js copied to clipboard
graphql
use named parameters for node visit context info
Motivation:
- Some visit context information is rarely used, this could be pathway toward refactoring, future-proofing any breaking changes to come. (see: https://github.com/graphql/graphql-js/issues/3225)
- Eventually, BREAK and/or other visit controllers could be added as third argument directly to the visitor method rarely than exported from the library. (see https://github.com/graphql/graphql-js/pull/3616)
Deploy Preview for compassionate-pike-271cb3 ready!
| Name | Link |
|---|---|
| Latest commit | d1e318051f10b7c9b0b6bd8f0df70fd730208eeb |
| Latest deploy log | https://app.netlify.com/sites/compassionate-pike-271cb3/deploys/62990e7848527600095adb7f |
| Deploy Preview | https://deploy-preview-3619--compassionate-pike-271cb3.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
Thanks for taking a look. We could try to rework as new format that is optional in v17 but required in v18.
Alternatively we could backport the backwards compatible version to v16 and just deprecate in v17
Backwards compatible version is easier said than done. We can't just change the second argument to keyOrContext, because the directionality is actually opposite, our users are supplying the function, rather than us writing it. How would we know which type of function we were supplied and whether to pass the key or the context?
What seems possible, but not necessarily the best choice: we could make our users specify in some way which type of visitor function they are passing, and then require them to pass it that way. Easiest but ugliest, we could create an entire new function called visitWithNamedVisitorFnArguments that supercedes visit and then deprecate visit.
Adding to next js-wg. If you are reading this, please feel free to chime in.
@yaacovCR As a suggestion to allow a faster review cycle, can we have a rule where PRs either blocked on the technical solution or WG discussion is marked as draft? https://github.blog/changelog/2020-04-08-convert-pull-request-to-draft/
This will make the "Pull requests" tab more representative.
