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

101–110 of 127 posts

Re: Advice on JSX Conditionals

#101

Post by favorited »

jkcxn wrote: post #35
molf wrote: post #3

I've always found these approaches to writing conditions in JSX to be terrible. Wouldn't it be nice if JavaScript were an expression-oriented language? Then you could just write: {if (gallery.length) { }} There has been a "do expressions" proposal [0] for many years, which addresses this (though it is more verbose). I hope it will be accepted some day. [0] https://github.com/tc39/proposal-do-expressions

Yes Dart with Flutter and swift UI both had to add language features just to support if and loop expressions. But people writing immediate mode guis have been doing the exact same thing using standard language features for years. There's no reason you can't mix React-ive style components with an immediate style API. I do this in a GUI library I've written in D. The downside is you get slightly less type safety, but I…

> swift UI both had to add language features just to support if and loop expressions

The special syntax for loops in SwiftUI is important, because plain-old loops are always eager. For example, if you were building building a list using a loop, it would iterate over every item up-front to generate the list's body. With the `ForEach` struct, on the other hand, you provide the block to create each item, and it can be invoked lazily as the content will appear.

Re: Advice on JSX Conditionals

#102

Post by beaconstudios »

bacro wrote: post #80
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.

Micro-optimisations aren't useful. If you get to the point where the performance cost of inline functions is a bottleneck, you probably shouldn't be using React at all.

Re: Advice on JSX Conditionals

#103

Post by LAC-Tech »

conradludgate wrote: post #94
LAC-Tech wrote: post #84

IMHO this is an anti-pattern. This involves people writing giant blocks of JSX that are hard to read. Especially with && all over the place. Just split up your component into smaller components with max one conditional each. Related, can anyone tell me the origins of the bizarre react practice of one file per component? I'm assume some mega corp told people it was "best practice", but the end result is way too many f…

I'm assuming it dates back to class components and Class per File ideologies

Interesting! And yeah Class per file had the exact same problem - classes were big and did too much. And now everyone hates "OO"

Re: Advice on JSX Conditionals

#104

Post by erikpukinskis »

bacro wrote: post #80
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.

Won’t V8 just optimize this anyway? I doubt there’s any real difference in memory usage.

Re: Advice on JSX Conditionals

#105

Post by erikpukinskis »

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.

Yeah, I think nested ternaries are fine as long as it’s just a list like OP is suggesting…

But it breaks peoples brains for some reason so I rarely use them professionally.

It’s really not that hard though, the ? and : are just shorthand for “else if” and “then”.

Re: Advice on JSX Conditionals

#106

Post by bacro »

beaconstudios wrote: post #102
bacro wrote: post #80

Earlier quoted context omitted.

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

Micro-optimisations aren't useful. If you get to the point where the performance cost of inline functions is a bottleneck, you probably shouldn't be using React at all.

Maybe, but I just prefer to have a named function defined with a useCallback and just call it.

Re: Advice on JSX Conditionals

#107

Post by jameshart »

eyelidlessness wrote: post #76
jameshart wrote: post #45

Earlier quoted context omitted.

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.

What if you consider it as ‘only returns a data structure that requests the rendering of if someBool is true’?

If you write

    console.log(someBool && “anything”)
Are you altering the control flow because the console window will call a different bit of font evaluation code to render “anything” instead of “false”?

Or are you just conditionally evaluating an expression that results in different data that causes different downstream effects?

Evaluating doesn’t do anything. It doesn’t make any DOM elements. It doesn’t trigger any useEffects. It just returns an object that has the potential to be hooked into a react renderDOM lifecycle to provide further instructions on what the DOM should look like and what other core should run.

Re: Advice on JSX Conditionals

#108

Post by eyelidlessness »

9wzYQbTYsAIc wrote: post #97
eyelidlessness wrote: post #93

Earlier quoted context omitted.

Okay: only evaluates if someBool is true. The value of someBool quite literally controls which code path is taken. It’s even more clear with a fallback: { someBool && || } Which would more idiomatically be written as a ternary conditional, but still. It doesn’t matter where the expression is placed, it’s the same if you assign it to a variable: const el = someBool && || ; Or even just as an expression statement: some…

> It doesn’t matter where the expression is placed, it’s the same if you assign it to a variable If you separate the concern of the condition definition from the conditional rendering, by pulling the conditional’s definition into a variable, you do get enhanced portability, though. Much easier to port between languages and frameworks if your conditional definition can be copy-and-pasted out without having to mess wit…

I’m not sure whether I agree or disagree with this. But I do want to clarify that my intent was not to argue for or against conditional expressions in any code position, only to address the factual question of whether they constitute control flow.

Re: Advice on JSX Conditionals

#109

Post by bacro »

erikpukinskis wrote: post #104
bacro wrote: post #80

Earlier quoted context omitted.

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

Won’t V8 just optimize this anyway? I doubt there’s any real difference in memory usage.

I am not sure, it has a closure for the 'error' local variable.

Re: Advice on JSX Conditionals

#110

Post by jameshart »

eyelidlessness wrote: post #93
9wzYQbTYsAIc wrote: post #90

Earlier quoted context omitted.

and if that expression-body is wrapped within the render() method.

Okay: only evaluates if someBool is true. The value of someBool quite literally controls which code path is taken. It’s even more clear with a fallback: { someBool && || } Which would more idiomatically be written as a ternary conditional, but still. It doesn’t matter where the expression is placed, it’s the same if you assign it to a variable: const el = someBool && || ; Or even just as an expression statement: some…

But the short circuiting doesn’t matter.

You could go

   let x = ;
   return someBool && x;
And the result (assuming well behaved react code) would be the same. is just a literal expression. It doesn’t matter whether it gets evaluated or not.

You’re not using && shortcircuiting to prevent from being evaluated - it doesn’t matter if it gets evaluated. You are using it to decide which value to return.

This really isn’t ‘using shortcircuiting for control flow’. It’s just using && as an operator in an expression evaluation.

Post reply on HN