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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃殌 Feature: make no-unused-variables more permissive #1515

Open
2 tasks done
sys13 opened this issue May 10, 2024 · 1 comment
Open
2 tasks done

馃殌 Feature: make no-unused-variables more permissive #1515

sys13 opened this issue May 10, 2024 · 1 comment
Labels
status: in discussion Not yet ready for implementation or a pull request type: feature New enhancement or request

Comments

@sys13
Copy link
Sponsor

sys13 commented May 10, 2024

Bug Report Checklist

Overview

I would suggest the following changes:

'@typescript-eslint/no-unused-vars': [
	'error',
	{
		argsIgnorePattern: '^_',
		caughtErrors: 'all',
		ignoreRestSiblings: true,
		varsIgnorePattern: '^_',
	},
],

This can help in the common React case of const [_, setMyVar] = React.useState() where you want to do array restructuring but don't want to keep the first argument. The other cases apply to (myVar, ...rest) => ... and function(_, stuff) which is useful when composing functions.

Additional Info

No response

@sys13 sys13 added the type: feature New enhancement or request label May 10, 2024
@JoshuaKGoldberg
Copy link
Owner

Heya thanks for the suggestion @sys13!

const [_, setMyVar] = React.useState()

Is there a reason you don't want to do const [, setMyVar] = React.useState()?

Also: I'm under the impression it's a bit of an antipattern / discouraged to set up state like this. Most React practices I've seen have encouraged keeping to simple state primitives and not relying on API details like "there's a rerender if I update this never-used state". Is there a reproduction case you can post for why you'd really want this?

The other cases apply to (myVar, ...rest) => ... and function(_, stuff) which is useful when composing functions.

Similar question here. My general impression has been that having to declare unused parameters is a symptom of confusing code styles. I worry that this is not a particularly common need - so might not make sense as the default in a general-purpose create-*-app?

@JoshuaKGoldberg JoshuaKGoldberg added the status: in discussion Not yet ready for implementation or a pull request label May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: in discussion Not yet ready for implementation or a pull request type: feature New enhancement or request
Projects
None yet
Development

No branches or pull requests

2 participants