react/jsx-key is triggering false positive for props defined as an object properties

[awthwathje]

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.

[ljharb]

This is actually intentional, and in a future version of React key I 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.

[awthwathje]

Then I think it is good idea to explicitly mention this in the documentation.

[ljharb]

Sure, a PR to add that to the jsx-key docs would be great!

[awthwathje]

Duh... Well, okay. Will do it.

[jeremywiebe]

@ljharb Sorry to revive an old Issue. I was wondering if you could point to some React docs that talk about this:

in a future version of React key I believe won't be possible to spread, it will only be allowed statically provided.

[ljharb]

reactjs/rfcs#107

[machineghost]

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?

[ljharb]

@machineghost this is an eslint rule, as such, it's opinionated by design. The entire purpose of eslint rules is to choose which 100% valid code is marked as invalid - otherwise you'd just rely on syntax errors and not use eslint at all.

The intention of this rule is for key to be statically hardcoded inline, not spread in. If you don't like that, disable the rule.

[machineghost]

@ljharb Yes, I 100% agree: ES Lint is opinionated, by design ... but it has historically never been so opinionated as to refuse to even consider an option for (again) perfectly valid code.

On the contrary, ESLint is FULL of options to rules. There are quite literally hundreds of ways to customize various ES Lint rules in existence.

Thus, saying "The only way to get ES Lint to accept perfectly valid code is to completely disable a rule (and lose the benefit of all of the other meaningful/valid cases that it catches) ... and won't even consider adding an option" seems significantly inconsistent with the rest of the ES Lint rules to me.

[ljharb]

You're certainly right that there's lots of options; but eslint core has in fact often refused to add options for otherwise valid code, as have various plugin maintainers. You're more than welcome to create your own plugin, compose any existing rule, and modify (or add to) the reports it generates (see eslint-rule-composer).

I can certainly see the rule being modified, without an option, to allow an inline spread static key (the OP's case), and I'd be happy to review a PR that did that.

[machineghost]

From "ES Lint eslint-plugin-react doesn't want your garbage (but 100% valid) code" to "happy to review a PR" in only one comment ;) Thank you!!

[machineghost]

I can certainly see the rule being modified, without an option, to allow an inline spread static key (the OP's case), and I'd be happy to review a PR that did that.

P.S. Why "without an option"? Couldn't there be users who want the current behavior? An option seems safer ...

[ljharb]

That's a fair point; the option would be needed when React makes spreading key invalid, might as well add it now.

[machineghost]

That's a fair point; the option would be needed when React makes spreading key invalid, might as well add it now.

IF React makes spreading key invalid. Again, nothing has happened on that for two years, so ... maybe you shouldn't hold your breath waiting for it ;)

Never worked on an ES Lint rule before but I'll see if I can pick it up and submit a PR.

[ljharb]

React 17 hasn't come out after more than 2 years of work - so far they ship almost all their plans eventually, even if on a scale of years.

[machineghost]

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 :)