Skip to content

Add react/no-array-index-key rule example to documentation #2220

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

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions docs/rules/no-array-index-key.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,19 @@ The `key` is used by React to [identify which items have changed, are added, or

It's a bad idea to use the array index since it doesn't uniquely identify your elements. In cases where the array is sorted or an element is added to the beginning of the array, the index will be changed even though the element representing that index may be the same. This results in unnecessary renders.

## Example

Add to your eslint configuration file (usually `.estlintrc`)

```
{
"rules": {
"react/no-array-index-key": 0 // 0 = off, 1 = warn, 2 = error
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

generally we don't document things like this, because it's basics of how eslint itself works. It's assumed that users of an eslint plugin know how eslint works.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point but, as an eslint user, sometimes I found that there're many rules that either exptects a string like error or warn, while others could expect numbers, booleans or even objects or arrays. This made me waste some time until I found some example in the web about the correct usage of a specific rule.

I personally think that documenting this doesn't distract the user and also helps on document how this specific rule works.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If so, then let's also audit every other rule doc, and make sure they all document themselves the same way?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(do note tho, every rule without exception supports 0/1/2 or "off"/"warn"/"error"; the variability is only in additional configuration arguments)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd love to see every rule documented, but as you know there're a lot of them and it's better to start at some point if you truly consider it.
On the other side (and since I don't consider myself a an advanced eslint user), I wasn't fully aware of that rule (my bad for don't reading the eslint docs ✋).
As a conclusion, I see that you have a valid point about being redudant adding this as a documentation, but maybe it could help some begginers or anxiety devs like me :).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely think reducing confusion is good; but i don't think doing it piecemeal is likely to be effective.

}
}

```

## Rule Details

The following patterns are considered warnings:
Expand Down