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

91–100 of 127 posts

Re: Advice on JSX Conditionals

#91

Post by 9wzYQbTYsAIc »

postalrat wrote: post #88
9wzYQbTYsAIc wrote: post #73

Earlier quoted context omitted.

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.

What if you wanted to get the boolean value of number but with not. Would you write: !Boolean(n) Or would you write: !n

if 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.

Re: Advice on JSX Conditionals

#92

Post by tshaddox »

9wzYQbTYsAIc wrote: post #78
tshaddox wrote: post #75

Earlier quoted context omitted.

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

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

I don't know whether that principle is generally true or ought to be generally true, but React does throw a runtime error if you render a plain JS object as a React child. This can probably also be prevented at compile time with linters or TypeScript, but given that React has to do something at runtime if it encounters an invalid child, I think throwing an error is preferable to just rendering nothing or having some undefined behavior.

In my opinion, rendering `null` is a pretty clear and explicit way to indicate you don't want to render anything. But rendering `false` (or `true`, for that matter) is not at all so clear to me. I think throwing a runtime error would be better, and would largely make the `thing && ` idiom go away.

Re: Advice on JSX Conditionals

#93

Post by eyelidlessness »

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

Earlier quoted context omitted.

Can’t speak for GP, but for me, because: { someBool && } … only renders if someBool is true.

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:

    someBool &&  || ;

Re: Advice on JSX Conditionals

#94

Post by conradludgate »

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

Re: Advice on JSX Conditionals

#95

Post by brimble »

eyelidlessness wrote: post #79
brimble wrote: post #47

Earlier quoted context omitted.

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

Agree, the problem with if/else is that you end up having to consider the whole block plus usually a little context from just before it. I still find it much easier to read, unless very poorly written, while all ternaries slow me down every single time I read one, no matter how well-written. I struggle to parse them into ideas and words and to follow the order of events, seemingly no matter how many times I encounter them. They just feel wrong. All that implicit scoping crammed into one line, relying on memory and active searching to find the boundaries and then follow the order of events back "to the top", rather than having them explicitly marked.

Re: Advice on JSX Conditionals

#96

Post by 9wzYQbTYsAIc »

tshaddox wrote: post #92
9wzYQbTYsAIc wrote: post #78

Earlier quoted context omitted.

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

> The React framework strives for catching everything at compile-time. Runtime errors are a big no-no in web development. I don't know whether that principle is generally true or ought to be generally true, but React does throw a runtime error if you render a plain JS object as a React child. This can probably also be prevented at compile time with linters or TypeScript, but given that React has to do something at ru…

I get what you are saying. In my experience, it ends up being moot when you are explicitly trying to avoid runtime errors, because you’ll need something along the lines of “guard() && ” or you could simply have “” and then within Component render have “if (!guarded) return ”, etc.

At that point, you’ll probably need to worry about component collections containing empty elements, though. That pulls you back into the parent scope, anyways.

There’s probably a nicer way to handle it with custom hooks, though.

> I don't know whether that principle is generally true or ought to be generally true

They sure do go out of their way to make misuse of hooks a compile-time error. I think that those useful error messages go a long way to rectifying the archaic semicolon error messages of the C days.

Re: Advice on JSX Conditionals

#97

Post by 9wzYQbTYsAIc »

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…

> 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 with untwining the previous developers expression statements.

Re: Advice on JSX Conditionals

#98

Post by masterofmisc »

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 ; } })()}

Oh, I like this. Thanks.

Re: Advice on JSX Conditionals

#99

Post by dbetteridge »

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.

It 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

Re: Advice on JSX Conditionals

#100

Post by phailhaus »

heyparkerj wrote: post #56
phailhaus wrote: post #52

Earlier quoted context omitted.

If you're using Typescript that can get a bit annoying, since you'll also need to pass in whatever props necessary for the function to handle the logic + type them. Makes it nice and easy to test in isolation though.

Typically the function has access to whatever props or state it needs because it's in the scope of the component. It's not pure, but it's rare that I need to verbosely pass props into the function call and then accept them in myFunction. I don't typically test these functions in isolation as the component itself is pure and I test the output of the component as a whole instead.

Oh gotcha, I thought this was a function that was defined outside of the component.
Post reply on HN