[New] jsx-no-leaked-render: add ignoreAttributes option

[aleclarson]

Fixes #3292

When ignoreAttributes is true, validation of JSX attribute values is skipped.

Todo

• write docs

[codecov]

Codecov Report

Attention: Patch coverage is 90.90909% with 1 line in your changes missing coverage. Please review.

Project coverage is 97.65%. Comparing base (5c23573) to head (ab154a4).

Files with missing lines	Patch %	Lines
lib/rules/jsx-no-leaked-render.js	90.90%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3441      +/-   ##
==========================================
- Coverage   97.71%   97.65%   -0.06%     
==========================================
  Files         133      136       +3     
  Lines        9958     9981      +23     
  Branches     3693     3696       +3     
==========================================
+ Hits         9730     9747      +17     
- Misses        228      234       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[levrik]

I think ignoreProps would be a more suitable name here.

[ljharb]

Can you elaborate on the use case here?

Certainly the component you're passing the prop value to might not be directly rendering it - but I'm not sure why that makes it OK to pass a renderable falsy value.

[aleclarson]

Can you elaborate on the use case here?

Certainly the component you're passing the prop value to might not be directly rendering it - but I'm not sure why that makes it OK to pass a renderable falsy value.

The use case is preferring to avoid false positives. The component receiving the prop is responsible for avoiding leaky render. Many prefer to keep the warning local to where the prop is actually rendered.

[ljharb]

I see - so you're saying, you still want to report on leaky renders on DOM elements, but you don't want to do that on props on custom elements so that the custom component has the responsibility to check for it?

In that case, what i'd expect is that this could be ignoreNonDOMProps, and it would only suppress warning on props of non-DOM elements - would that meet your use case?

[tcl333]

This rule is unusable to me until this PR is landed. I need to handle a very basic usecase of <Component isFooBar={isFoo && isBar}>. This rule currently auto-breaks that line by converting it into <Component isFooBar={isFoo ? isBar : null }>. My component doesn't take null as a prop, nor should it be required to.

[l1135677068]

I want to know how to use the ignoreAttributes option?
i use it like belows code, but it throw an error.

  "react/jsx-no-leaked-render": ["error", { "validStrategies": ["coerce"], ignoreAttributes: true }]

Is there a use case that i can refer to?

[ljharb]

@l1135677068 this PR isn't merged yet, and thus can't be released yet either, so you can't use it yet.

[ljharb]

I've just rebased this PR; it's ready to go once there's documentation. If someone wants to leave a code review suggestion, I can pull it in and land this.

[l1135677068]

If someone wants to leave a code review suggestion, I can pull it in and land this.

ok, i get it.

[mikedidomizio]

I think considering this PR has been open for 2 years without movement from the author (who is active), it's potentially safe to say they have higher priorities at this time.

I would suggest to get this past the finish line, by someone championing it and picking up where the original author left off. Fork his fork, make the necessary documentation changes, and create a separate pull request, and mention this one. @artemxknpv you wrote a documentation change suggestion, maybe you'd like to take this on?

It's so close, and it's crazy to me that 2 years have passed on this and all it required were some documentation updates.

I would also suggest that ignoreAttributes be replaced with ignoreProps or ignoreNonDOMProps like @ljharb has suggested. I think ignoreProps is much more concise and simple but that's my opinion.

[ljharb]

Seems pretty good.

[CruuzAzul]

I agree with the use of ignoreProps, which I think is more in line with what the props do. Does anyone have any idea how much more needs to be done on the PR before we can merge? 🤗 Maybe @ljharb