-
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
add eslint rules for promises #3796
Conversation
✅ Deploy Preview for compassionate-pike-271cb3 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
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:
|
This ends up being a "bug fix" because it does remove an extra tick and so is observable. |
660c90c
to
b057bc9
Compare
da0a5a4
to
f1ba488
Compare
b66bdd3
to
1c39356
Compare
For simplicity, I have dropped the specialized helpers, provider just a single |
...and enable basic rules
leads to one less tick in `executeStreamField` in the branch where completion of a non-promise yields a promise.
errors avoided by previously avoiding then/catch
we can't fix then, but we can replace it. instead of using immediately invoked anonymous asynchronous arrow functions, we can replace the then method with then-like helper functions. In fact, we can optimize these small helpers to the exact cases we need. = after() => helper with only onFulfilled callback = catchAfter => helper with onError callback that handles promise rejection = tryAfter => helper with synchronous onFulfilled callback and onError callback that handles promise rejection and onFulfilled exceptions
Motivation: It is faster to await a promise prior to returning it from an async function than to return a promise with `.then()`. See: https://github.com/tc39/proposal-faster-promise-adoption Previously, this eslint rule errored by default only 'in-try-catch'.
`after` becomes sync, requiring no return type check for the onFulfilled result.
Closing this, see edited comment on #3754. The real world implications of the extra tick within |
We could not demonstrate via actual benchmarking that the tick reduction from awaiting a promise prior to returning it translates into real-world performance gains. See graphql#3796. In any case, the promise must be awaited (irrespective of performance) to allow the catch block to handle rejection errors. Simply returning `completed` would result in test failures.
We could not demonstrate via actual benchmarking that the tick reduction from awaiting a promise prior to returning it translates into real-world performance gains. See #3796. In any case, the promise must be awaited (irrespective of performance) to allow the catch block to handle rejection errors. Simply returning `completed` would result in test failures.
UPDATE:
After much testing, I am unable to generalize the speed savings from #3754, so this PR has been closed.
See #3754 for further discussion.
prefer-await-over-promises helps avoid extra ticks, formalizing the optimization from #3754 across the board
various additional rules add additional best practices with regard to promise use with at most trivial code changes