You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
React uses key as a special prop name that you pass in when mapping over a list. If you try to access a prop named key from within a component, it will be undefined. It's easy to accidentally name a prop key and cause your code to not work. Something like the following buggy code causes no eslint errors when using this plugin's recommended ruleset. (Also, if you do this in TypeScript, the runtime value of key does not align with what the type system says is happening, since the type system believes it's guaranteed to be a string, but it actually ends up being undefined since React doesn't pass the prop through).
For me personally, even though I've been working in React a long time, I'll still occasionally do this, and it takes a while to notice my mistake, since you have to notice the incorrect behavior at runtime and then chase down why it's happening. I can imagine that this could be a really difficult bug for a junior to debug.
A rule for this should probably also disallow naming a prop ref, and maybe any other special React prop names that I'm not thinking of?
Could call this rule react/no-restricted-prop-names or something?
To implement this rule, it seems like a good starting point might be to copy the code from lib/rules/no-unused-prop-types.js. I'd take a crack at implementing this myself, if people think it's a good idea.
The text was updated successfully, but these errors were encountered:
Hmm, I could have sworn we already had a rule for this.
So basically, a rule that covers component props (as opposed to element props), and forbids trying to accept a key or ref prop, or whatever else might be "special" for React?
I also believe React may be changing this for one or both of those, for what it's worth, so that'll be important to verify.
Hmm, I could have sworn we already had a rule for this.
I looked for one, and I don't think there is one. I checked all the rules with "prop" in the name, although I could have overlooked something. (At the very least, if there is a rule for this, it's definitely not enabled by the recommended ruleset, because I ran into this recently in a codebase that's using the recommended ruleset on a very recent version of this package.)
So basically, a rule that covers component props (as opposed to element props), and forbids trying to accept a key or ref prop, or whatever else might be "special" for React?
Yeah, exactly
I also believe React may be changing this for one or both of those, for what it's worth, so that'll be important to verify.
Do you remember where you heard this, or know who would know more about it?
React uses
key
as a special prop name that you pass in when mapping over a list. If you try to access a prop namedkey
from within a component, it will be undefined. It's easy to accidentally name a propkey
and cause your code to not work. Something like the following buggy code causes no eslint errors when using this plugin's recommended ruleset. (Also, if you do this in TypeScript, the runtime value ofkey
does not align with what the type system says is happening, since the type system believes it's guaranteed to be a string, but it actually ends up being undefined since React doesn't pass the prop through).For me personally, even though I've been working in React a long time, I'll still occasionally do this, and it takes a while to notice my mistake, since you have to notice the incorrect behavior at runtime and then chase down why it's happening. I can imagine that this could be a really difficult bug for a junior to debug.
This seems to be a fairly common issue for people, based on the traffic that this stackoverflow post gets: https://stackoverflow.com/questions/33661511/reactjs-key-undefined-when-accessed-as-a-prop
A rule for this should probably also disallow naming a prop
ref
, and maybe any other special React prop names that I'm not thinking of?Could call this rule
react/no-restricted-prop-names
or something?To implement this rule, it seems like a good starting point might be to copy the code from
lib/rules/no-unused-prop-types.js
. I'd take a crack at implementing this myself, if people think it's a good idea.The text was updated successfully, but these errors were encountered: