Skip to content
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

Fix no-template-arrow false positives #189

Open
jpzwarte opened this issue Nov 20, 2023 · 3 comments
Open

Fix no-template-arrow false positives #189

jpzwarte opened this issue Nov 20, 2023 · 3 comments

Comments

@jpzwarte
Copy link

jpzwarte commented Nov 20, 2023

These are currently marked as invalid:

  • @click=${() => this.#onRetry(file)}
  • @click=${async () => await this.#onDelete(file)}

I believe they are false positives since the arguments to the method do not match the arguments of the arrow function.

The rule should only be applicable when the arguments to the arrow function match the arguments of the called function.

@43081j
Copy link
Owner

43081j commented Nov 27, 2023

this is an interesting one, really a question of the intent of this rule

the original intent of the rule wasn't necessarily to catch problems (i.e. incompatible signatures for events), it was to encourage moving listeners into methods or variables instead of inlining them.

at the time in particular, best practice seemed to be to avoid arrow funcs so we don't create a new function every time we render. but there's little overhead there now (if there ever was), since lit will just change the reference and keep the same listener.

ultimately, its turned into a stylistic rule instead - people (not everyone ofc) preferring interpolating references rather than inline functions.

in your situation, i'd just turn it off since your stylistic preference doesn't agree with it. and maybe remove it from the recommended rule set.

if we repurpose the rule to be about types (e.g. args matching), we're stepping on the toes of typescript and probably shouldn't be.

@jpzwarte
Copy link
Author

in your situation, i'd just turn it off since your stylistic preference doesn't agree with it. and maybe remove it from the recommended rule set.

Right, I've already disabled it. And to avoid future confusion, I think removing it from the recommended rule set might be a good idea!

if we repurpose the rule to be about types (e.g. args matching), we're stepping on the toes of typescript and probably shouldn't be.

Right, as you explained, this would change the intention of the rule significantly.

@43081j
Copy link
Owner

43081j commented Nov 28, 2023

ill open a pr when i get chance to remove it from the recommended config (unless you beat me to it!)

thanks for raising it, its a pretty old rule and doesn't have as much meaning anymore

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants