-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
Wrong async/await/preventDefault usage #17448
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
Comments
Yes, this My point thought is that anything that involved loading of additional JS chunks ( |
Including However the loading should only affect the code which uses the modules. We do not need to do Generally speaking I think the code I refactored is on the right way. |
ps: the methods mentioned in "Examples of correct code for this rule" of https://github.com/github/eslint-plugin-github/blob/main/docs/rules/async-preventdefault.md , are the methods I used during refactoring. For exmple, this one: https://github.com/go-gitea/gitea/pull/17386/files#diff-1b029e915c1ca8d9b0d09ef0ce86797a36fbdca25ab233f179c14987a3bb0a05R137
|
Yeah, async IIFE seems to be the most elegant way to split a function into sync/async parts. |
Can you help to review the PR #17386 again? I hope it can be approved soon to continue other works. At least, it doesn't make thing worse than before. |
This is an issue for discussion of frontend refactoring. @lafriks @silverwind
The code https://github.com/go-gitea/gitea/blob/main/web_src/js/features/repo-legacy.js#L350 works like this:
The usage of async/await is incorrect. The
preventDefault
won't have effect because the event has been processed synchronously before (when the listener returned).So, that's why I insist to clean up most inconsistent await/async in the code base, only use them when it is necessary.
index.js
#17386We should do our best to make everything work as expected.
The text was updated successfully, but these errors were encountered: