41–50 of 127 posts
Most of these are just "tips on using conditionals" and have very little to do with JSX itself.
If you don’t like your conditional logic in your template just give them a name and explicit boolean type and be done with it.
Still a useful overview of common idioms though for people who just get started.
Hard disagree on nested ternaries, or rather chained ternaries, which are just as easy to read and reason about as chained if else statements: if (isA) { return A; } else if (isB) { return B; } else if (isC) { return C; } else { return D; } is equivalent to return isA ? A : isB ? B : isC ? C : D;
Sure, when you're neatly using booleans with names that are three characters long, this is super easy to parse. Now throw in long functions with multiple arguments, and all kinds of different access patterns and this ternary starts to look like a nightmare.
let x = somelongfunc(arg, blah(etc))
? value1
: some other condition
? value2
: fallback
Drives me nuts that there's no straightforward way to do a switch statement in JSX. {switch (page) { case 'home': return case 'about': return default: return }}
I'm surprised this doesn't work since you could easily externalize this to a function: {getCorrectComponent(page)} const getCorrectComponent = (page) => { switch (page) { case 'home': return case 'about': return default: return } }
const Content = ({page}) => {
switch (page) {
case 'home': return
case 'about': return
default: return
}
}It doesn’t necessarily have the same benefits in React, but folks ought to consider using components for control flow, like SolidJS does[1]. 1: https://www.solidjs.com/docs/latest/api#control-flow
Earlier quoted context omitted.
From the article: “{number && } renders 0 instead of nothing. Use {number > 0 && } instead.” Functional JSX would look like: const isNumber = number > 0; {isNumber && } You can similarly do things like: const isVisible = condition1 && (condition2 || condition3) || guard(props.input1); {isVisible && } The functional paradigm and some basic code factoring can make quick work of conditional JSX
Yes, 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)…
Earlier quoted context omitted.
From the article: “{number && } renders 0 instead of nothing. Use {number > 0 && } instead.” Functional JSX would look like: const isNumber = number > 0; {isNumber && } You can similarly do things like: const isVisible = condition1 && (condition2 || condition3) || guard(props.input1); {isVisible && } The functional paradigm and some basic code factoring can make quick work of conditional JSX
Another quick option for avoiding the "zero" issue: {!!number && }
Its more obvious what it achieves just at a glance.
Earlier quoted context omitted.
Sure, when you're neatly using booleans with names that are three characters long, this is super easy to parse. Now throw in long functions with multiple arguments, and all kinds of different access patterns and this ternary starts to look like a nightmare.
It's still often the cleanest way and I find myself doing something like this: let x = somelongfunc(arg, blah(etc)) ? value1 : some other condition ? value2 : fallback What I usually want is pattern matching expressions, but those are not in many languages.
Most of these are just "tips on using conditionals" and have very little to do with JSX itself.
True. Also many of these are not actual issues and are just behavior inherent to using JavaScript. If you don’t like your conditional logic in your template just give them a name and explicit boolean type and be done with it. Still a useful overview of common idioms though for people who just get started.
I agree - I just think labeling them as JSX issues is pretty disingenuous. JSX is literally just running them as standard js expressions here - which I actually find delightful: they work the same as they do in normal javascript (quirks included :D ).
The author seems to want something like ng-if="condition", and I find DSLs in this space a real abomination.
When logic gets more complicated than a single ternary (e.g., handling pending/error/result state), I've found that a `useMemo` gives me the flexibility I need. It also keeps the messy logic out of the final JSX, which tends to make it read better.
Earlier quoted context omitted.
Yes, 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)…
You can add do-expression proposal support in .babelrc: {do { if (user) { } else { } }} https://babeljs.io/docs/en/babel-plugin-proposal-do-expressi...
{user
?
:
}