New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: tsc backed jsx conditional rendering rule #2770
Comments
It seems like you just want |
I think that would do it, yes. |
happy to accept PR for a new option, say |
I have written eslint rules before so I am somewhat familiar with the concept. |
I'm just chiming in to say that I'd be happy to test this once you've implemented this option. |
Best option would be to play around in https://astexplorer.net/ to get a feel for the AST you're looking to target. From there you can craft an ESLint selector as best you can to target that AST. Then you need to work it into the rule. If you want a live playground for inspecting the type information that TS provides - https://ts-ast-viewer.com/ is an amazing site. |
<div>
{items.length && (
// ^ Unexpected number value in conditional. An explicit zero/NaN check is required.
<ul>
{items.map(item => <li>{item}</li>)}
</ul>
)}
</div> The only possible downside is that if you disable |
that is true - it will "just work" with the right options. We can add another section to the docs that say "if you want to strictly validate your JSX logical expressions do not output values, you should use this config" |
@bradzacher Yep. Let's add a paragraph to allowNumber and allowString options in docs that says it's useful to set them to false in react projects. I can send a PR. It's not a problem specific to JSX though. It applies everywhere where any value can be passed. |
This all comes down to how logical operators are used and how you sometimes use them only for their short-circuiting behavior. I remember that I have already suggested to have all the
but is it worth it to maintain such a complicated rule? I don't know. Another idea I had in mind would be to forbid These are just my random thoughts. I'm not proposing any of these. |
My team ran into pitfalls with non-boolean values while conditionally rendering in React Native, where it can cause the I looked into Requiring ternary expressions in JSX is an option but again feels like overkill when we're setting the right hand side of the ternary to Conditional rendering using && is a pretty normal pattern in React. What I'd really like is more specific rule for JSX expressions that will disallow: This type of rule seems very achievable with typescript-eslint. I'd be happy to open to a pull request with a proposal - something like |
To be clear - if we want to make a small enhancement to If the goal is something larger than that around JSX semantics / react logic - then that no longer lives within this project, and should instead be housed within As a rule-of-thumb - we want to keep this project generic and framework agnostic Type-aware lint rules aren't restricted to just this project - anyone and everyone is allowed (and encouraged) to build on top of our tooling to create type-aware lint rules and enrich the entire community. |
cool, I took a stab at implementing the rule using |
@hpersson Your work should be useful! 👍 This issue was marked as accepting PRs. Could you send PR to include your rule in this repo? |
How about a rule that is like return (
<p>Hello {name}</p> // report if name is not string
)
return (
<p>Items: {items.length && items.join(", ")}</p> // error: type number is not allowed in JSX expression
) It would also be useful to not forget to format numbers using user's language: // bad:
function ScoreCounter(props) {
return (
<p>{props.score} 🪙</p>
)
}
// good:
import { FormattedNumber } from "react-intl"
function ScoreCounter(props) {
return (
<p><FormattedNumber value={props.score} /> 🪙</p>
)
} I can send PR. |
In my view, for JSX conditional rule, we don't need any configurable options, it should only accept booleans and nulls, excluding any other falsy and truthy values. That way we can tackle all edge cases for React and React Native apps. |
Over at jsx-eslint/eslint-plugin-react#2073 we are discussing a rule that only the TSC could help with.
It would require to detect if a conditional rendering check for react JSX blocks of code is a true boolean value.
Do you think the JSX world and this eslint plugin could somehow be combined to create a rule (in a new package?) for this particular bad coding error (that will crash any react-native app)?
The text was updated successfully, but these errors were encountered: