8 ms·
From the article: “{number && <JSX />} renders 0 instead of nothing. Use {number > 0 && <JSX />} instead.” Functional JSX would look like: const isNumber = n
by 9wzYQbTYsAIc 5y ago
From the article:
“{number && <JSX />} renders 0 instead of nothing. Use {number > 0 && <JSX />} instead.”
Functional JSX would look like:
const isNumber = number > 0;
{isNumber && <JSX />}
You can similarly do things like:
const isVisible = condition1 && (condition2 || condition3) || guard(props.input1);
{isVisible && <JSX />}
The functional paradigm and some basic code factoring can make quick work of conditional JSX
- redler 5y agoAnother quick option for avoiding the "zero" issue: {!!number && <Thing />}
- 9wzYQbTYsAIc 5y agoOne of the joys of JavaScript, right there: not-not sorry.
- dbetteridge 5y agoBetter to use Boolean(number) Its more obvious what it achieves just at a glance.
- postalrat 5y ago"!!" should be pretty obvious to any javascript developer.
- 9wzYQbTYsAIc 5y agoNonetheless, better for the industry if we start to embrace more uniformity in our idioms. You can practically copy-and-paste between JavaScript and C# these days, with some trivial text replacement tweaks, if you are careful with your idioms.
- postalrat 5y agoWhat if you wanted to get the boolean value of number but with not. Would you write: !Boolean(n) Or would you write: !n
- 9wzYQbTYsAIc 5y agoif it were C#, I’d write it along the lines of !(n as bool), but for the purposes of JS, I suppose something like: const IsNumber = (value) => Boolean(value); !IsNumber(n) I’m not a fan of using the return-type as the function name, especially when you are really just trying to find out if something is a number.
- dbetteridge 5y agoIt might be, but not everyone knows js and I don't expect future people to be me. More obvious and more readable is always better
- molf 5y agoYes, I'm well aware of how to use these. I will elaborate on why I think it's terrible (even though there is no alternative in standard JS yet): * It encourages JSX-specific idioms. Outside of JSX, using `&&` instead of `if` for control flow would raise eyebrows from most people, I think. * I find it easier and faster to refactor `if` statements to `if/else` and vice versa (only requires addition or deletion of code) than to refactor `&&` to a ternary operator and vice versa (also requires modifying existing code). * Multiple nested ternary operators almost immediately become a mess, while a series of `else if` expressions (if such a thing existed) seem perfectly readable.
- 9wzYQbTYsAIc 5y agoIt’s generally better to go with the idioms of the language, sure, but in this case, the idioms of JSX work well and they are future-proof. If JavaScript adds the support that you are looking for, it would be easy enough for a static code analyzer to rewrite “&&” as “if”
- hombre_fatal 5y agoYou can add do-expression proposal support in .babelrc: <div> {do { if (user) { <Logout /> } else { <Login /> } }} </div> https://babeljs.io/docs/en/babel-plugin-proposal-do-expressions https://babeljs.io/docs/en/babel-plugin-proposal-do-expressi...
- Izkata 5y agoOr, no need to enable anything: {user ? <Logout \> : <Login \> }
- couchand 5y agoOk this thread just reached peak JavaScript.
- christophilus 5y ago