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

[Bug]: react/destructuring-assignment inconsistent behavior #3828

Closed
2 tasks done
moses-crasman opened this issue Sep 19, 2024 · 2 comments · Fixed by #3835
Closed
2 tasks done

[Bug]: react/destructuring-assignment inconsistent behavior #3828

moses-crasman opened this issue Sep 19, 2024 · 2 comments · Fixed by #3835

Comments

@moses-crasman
Copy link

Is there an existing issue for this?

  • I have searched the existing issues and my issue is unique
  • My issue appears in the command-line and not only in the text editor

Description Overview

Brief description

It appears the react/destructuring-assignment rule is not behaving consistently with type definitions.

Code example

type Props = { text: string };
export const MyComponent: React.FC<Props> = (props) => {
  return <div>{props.text}</div>;
  //           ^^^^^^^^^^
};

export const MyOtherComponent: React.FC<Props> = (props) => {
  const { text } = props;
  type MyType = typeof props.text;
  return <div>{text as MyType}</div>;
};

What is happening? / What is the error?

  • In MyComponent, linter gives a react/destructuring-assignment error.
  • In MyOtherComponent linter stays silent.

To me this appears as an unexpected inconsistency.

What command(s) did you run to reproduce issue?

Using the code example above;

npx eslint ./eslint-test.tsx

Expected Behavior

I would expect both components to trigger the linter rule.

eslint-plugin-react version

v7.34.3

eslint version

v8.57.0

node version

v18.20.2

@ljharb
Copy link
Member

ljharb commented Sep 23, 2024

I can indeed reproduce this, even when both snippets define a Props type, infer typeof props.text, and as MyType.

@ljharb
Copy link
Member

ljharb commented Sep 23, 2024

ok, so this is happening because the rule is counting props references, and in the second snippet, there's more than one, so it bails out.

If I comment out that propsRefs.length check, then the autofix fails to account for all of the other references, and that causes broken output.

I think the rule needs to be made smarter, by autofixing everything that references a property of props, but also not warning when there's any bare references to props that aren't destructuring it.

ljharb added a commit that referenced this issue Sep 23, 2024
golopot added a commit to golopot/eslint-plugin-react that referenced this issue Sep 29, 2024
golopot pushed a commit to golopot/eslint-plugin-react that referenced this issue Sep 30, 2024
golopot added a commit to golopot/eslint-plugin-react that referenced this issue Sep 30, 2024
golopot added a commit to golopot/eslint-plugin-react that referenced this issue Sep 30, 2024
golopot added a commit to golopot/eslint-plugin-react that referenced this issue Sep 30, 2024
@ljharb ljharb closed this as completed in 63aceff Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
2 participants