eslint-plugin-react: react/jsx-key is triggering false positive for props defined as an object properties
Sometimes it is useful to define a component call as
<Component {...{ key: id, id, shortTitle }} />
instead of
<Component key={id} id={id} shortTitle={shortTitle} />
but in the first case ESLint gets mad about the missing key prop, triggering the react/jsx-key rule.
This is the reason why I’m turning this rule off for now. I believe this should be fixed.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 16 (9 by maintainers)
Commits related to this issue
- Added key object spread example Spreaded key is discouraged and currently triggering the rule. Added some clarification to the doc. Resolves yannickcr/eslint-plugin-react#1753. — committed to awthwathje/eslint-plugin-react by awthwathje 6 years ago
- Added support (without options ... which are still to come) for spread (ie. ...) arguments with keys to be considered as valid as explicit key attributes Part of https://github.com/yannickcr/eslint-p... — committed to machineghost/eslint-plugin-react by machineghost 4 years ago
https://github.com/reactjs/rfcs/pull/107
Can we take a step back here? We have a request for a change to React, which may never happen … and because of that ESLint refuses to even provide the option to mark 100% valid code (today) as valid?
How does this make sense?
EDIT: Sorry, please disregard my previous post here; I think Prettier (which my VS Code is setup to run automatically) got run against the file and broke a bunch of things. Once I fixed the file it had 142 warnings … but 0 errors 😃
Duh… Well, okay. Will do it.
This is actually intentional, and in a future version of React
keyI believe won’t be possible to spread, it will only be allowed statically provided.The key should always be hardcoded; it’s not a normal prop.