-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
jsx-key rule should error on returning short hand fragments (<>) from iterators to avoid false negative #3657
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
These are arrays, not iterators, to be clear. #2365 is explicitly about fixing the error message when fragment shorthand is used - meaning, it does error. It can’t be auto fixed because we can’t pick the key for the developer. Can you provide a repro repo where it doesn’t error? |
@ljharb Here is a minimal repro built on |
@GNRSN are you perhaps unaware that there's a You shouldn't use "recommended" configs, including ours - you should use the airbnb config. |
@ljharb Thank you for pointing out my ignorance, as usual, the answer was in the documentation. I'm phasing in stricer lint rules in a large legacy code-base so starting out with the Airbnb config (which is from my limited experience with it, extremely strict) isn't really an option. |
I’d suggest starting with the Airbnb config and using overrides initially to allow existing files to violate whatever, and then gradually remove the overrides. That way, new files are in compliance. |
Issue
Mapping a list into multiple components per list element, surrounding them with jsx shorthand fragments
<>
currently results in no eslint error withjsx-key
rule enabled, even though React will warn/error about missing keys.According to the documentation, the recommendation is to instead always return full fragments from iterators, i.e.
See the short section in: https://react.dev/reference/react/Fragment#rendering-a-list-of-fragments
Suggestion
With the
jsx-key
rule enabled, shorthand fragments returned from an iterator should still error without key,fix
could update to<React.Fragment key={key}>
Motivation
Since missing keys can be pretty hard to debug, especially on fragments which won't show up in devtools, having eslint help with this would be extremely valuable instead of having to debug once it hits staging.
Misc
#2365 seems to be the most recent issue on this topic, discussing the removal of key requirement for shorthand fragments as they don't support it
The text was updated successfully, but these errors were encountered: