Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Advice on JSX Conditionals

thoughtspile.github.io

Post reply on HN
Print view View original

71–80 of 127 posts

Re: Advice on JSX Conditionals

#71

Post by eyelidlessness »

dimgl wrote: post #44
eyelidlessness wrote: post #2

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

Funnily enough, this has existed in React through a Babel plugin. I'm not sure why this hasn't really caught on. https://github.com/AlexGilleran/jsx-control-statements

I’ve encountered that, and kind of don’t understand why you’d need a Babel plugin. They’re trivial components to implement in regular JSX.

Re: Advice on JSX Conditionals

#72

Post by kipple »

eyelidlessness wrote: post #2

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

Agreed. I particularly like the look of their `/` component[1]:

  Not Found}>
Which doesn't seem to have an analog in the React babel-plugin[2] or standalone lib[3]

[1] https://www.solidjs.com/docs/latest/api#%3Cswitch%3E%2F%3Cma...

[2] https://github.com/AlexGilleran/jsx-control-statements

[3] https://github.com/samuelneff/react-control-flow

Re: Advice on JSX Conditionals

#73

Post by 9wzYQbTYsAIc »

postalrat wrote: post #65
dbetteridge wrote: post #46

Earlier quoted context omitted.

Better to use Boolean(number) Its more obvious what it achieves just at a glance.

"!!" should be pretty obvious to any javascript developer.

Nonetheless, 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.

Re: Advice on JSX Conditionals

#74

Post by bluefirebrand »

dlbucci wrote: post #68
tobr wrote: post #36

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;

Especially if you format them well. Just use a newline before each `:` and maybe after each `?` (if the value expressions are large), and it'll look great. return isA ? A : isB ? B : isC ? C : D

This looks fine as an example right here, but it starts to look terrible if there's larger or multiline boolean expressions involved, while if/else if winds up still being pretty readable.

Re: Advice on JSX Conditionals

#75

Post by tshaddox »

molf wrote: post #22
9wzYQbTYsAIc wrote: post #11

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)…

> Outside of JSX, using `&&` instead of `if` for control flow would raise eyebrows from most people, I think.

Very much so, at least for me. Relying on the short-circuiting of logical operators is fine, but only when you're actually going to use the resulting value. In the case of JSX, this is relying on the fact that `false` is a valid React child which renders nothing. Not only does this result in a mistake when the `&&` expression returns something like `0` that is falsey but isn't `false`, IMO it's already pretty awkward even if you are rendering `false`. I'd honestly prefer a runtime error, just like you get if you try to render a JS object, and only support rendering null and maybe undefined as React children.

Re: Advice on JSX Conditionals

#76

Post by eyelidlessness »

jameshart wrote: post #45
molf wrote: post #22

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)…

Why do you think of JSX’s use of && as control flow?

Can’t speak for GP, but for me, because:

    { someBool &&  }
… only renders if someBool is true.

Re: Advice on JSX Conditionals

#77

Post by [deleted] »

beaconstudios wrote: post #60

protip: you can use an IIFE (immediately invoked function expression) to put whatever conditionals or logic you want inside JSX! I use this all the time and it's much nicer for more complex blocks: {(() => { switch(state) { case 'loading': return ; case 'ready': return ; case 'error': return ; } })()}

[deleted]

Re: Advice on JSX Conditionals

#78

Post by 9wzYQbTYsAIc »

tshaddox wrote: post #75
molf wrote: post #22

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)…

> Outside of JSX, using `&&` instead of `if` for control flow would raise eyebrows from most people, I think. Very much so, at least for me. Relying on the short-circuiting of logical operators is fine, but only when you're actually going to use the resulting value. In the case of JSX, this is relying on the fact that `false` is a valid React child which renders nothing. Not only does this result in a mistake when th…

> I'd honestly prefer a runtime error, just like you get if you try to render a JS object

The React framework strives for catching everything at compile-time. Runtime errors are a big no-no in web development.

If I recall correctly, rendering null is behaviorally equivalent to not rendering, in React.

Re: Advice on JSX Conditionals

#79

Post by eyelidlessness »

brimble wrote: post #47
akvadrako wrote: post #42

Earlier quoted context omitted.

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.

Try as I might, I have to reason through ternaries every time I encounter them. I think the = being so removed from what it's actually assigning, but without grouping parens, is what messes me up. Plus I always forget what the punctuation characters mean—if/elseif/else uses words, so I don't have to remember.

> I think the = being so removed from what it's actually assigning, but without grouping parens, is what messes me up.

I almost always use grouping parentheses for this reason, unless it’s a very short single line expression. That said, if/else if/else has a different colocation problem: it puts the assignment further from the initial declaration, making its scope less obvious (unless you’re hoisting var, which is awful for its own reasons).

Re: Advice on JSX Conditionals

#80

Post by bacro »

beaconstudios wrote: post #60

protip: you can use an IIFE (immediately invoked function expression) to put whatever conditionals or logic you want inside JSX! I use this all the time and it's much nicer for more complex blocks: {(() => { switch(state) { case 'loading': return ; case 'ready': return ; case 'error': return ; } })()}

Waste of memory by creating new function objects on each render.
Post reply on HN