Possible jsx-no-allocation-in-props rule #1888
Conversation
| ## Rule Options | ||
|
|
||
| ```js | ||
| "react/jsx-no-allocation-in-props": [<enabled>, { |
There was a problem hiding this comment.
array literals, and object literals, should probably have separate controls
There was a problem hiding this comment.
I actually couldn't come up with a use case where an array would be supplied as a prop to a DOM component, that probably is not a valid case?
There was a problem hiding this comment.
for DOM components sure, but i meant, i should be able to configure this rule to only warn on object literals, or to only warn on array literals.
README.md
Outdated
| @@ -150,6 +150,7 @@ Enable the rules that you would like to use. | |||
| * [react/jsx-key](docs/rules/jsx-key.md): Validate JSX has key prop when in array or iterator | |||
| * [react/jsx-max-depth](docs/rules/jsx-max-depth.md): Validate JSX maximum depth | |||
| * [react/jsx-max-props-per-line](docs/rules/jsx-max-props-per-line.md): Limit maximum of props on a single line in JSX (fixable) | |||
| * [react/jsx-no-allocation-in-props](docs/rules/jsx-no-allocation-in-props.md): Prevent usage of `[]` and `{}` in JSX props | |||
There was a problem hiding this comment.
does this need a jsx- prefix? couldn't it also apply to React.createElement?
|
Oh yeah, a new rule (if we go that way) would have a different name. |
|
Removed |
alexzherdev
force-pushed
the
1633-jsx-no-allocation-in-props
branch
from
776638b to
027fb23
Compare
|
I don't think "allocations" is the best word to use in a memory-managed language, where allocations aren't user-observable. |
|
Oh, for sure, this name leaves much to be desired. I guess this is more |
ljharb
force-pushed
the
master
branch
6 times, most recently
from
59af733 to
865ed16
Compare
ljharb
force-pushed
the
master
branch
4 times, most recently
from
069314a to
181c68f
Compare
|
I see this was updated recently. Any chance it'll ship anytime soon? Would love to see this one live! |
|
@benasher44 it hasn't been updated since 2018; those 4 force pushes are to master, not this PR. If you'd like to help, please comment a link to an updated branch (NOT a new PR) and i can update this one :-) |
|
@ljharb just pushed to no-allocation-in-props in benasher44/eslint-plugin-react. Only thing I'm having trouble with right now is this error running the test locally: I get this error running other tests locally though too, so I think I'm just missing some configuration in my local env/setup. Any idea what it might be? |
|
Ah wait I think I figured that out. Hold please! |
|
Sweet okay pushed again. Tests pass now! |
|
Looks like last thing being discussed was naming. Are we good with |
|
@ljharb just checking in — happy to do the work if more is needed! |
ljharb
force-pushed
the
master
branch
2 times, most recently
from
380e32c to
51d342b
Compare
cc @ljharb
So... now that I know what future prospects are for
jsx-no-bind(#1633 (comment)) I actually have doubts that it makes sense to add this new rule on its own. The code here is basically the same asjsx-no-bind. Perhaps we could instead just update that rule to handle object creation. Thoughts?