Advice on JSX Conditionals • Hacker News Board

Re: Advice on JSX Conditionals

#31

Post by 9wzYQbTYsAIc » Wed, Mar 09, 2022, 5:16 PM UTC

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

It’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”

Re: Advice on JSX Conditionals

#32

Post by hombre_fatal » Wed, Mar 09, 2022, 5:17 PM UTC

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

You can add do-expression proposal support in .babelrc:

    
    {do {
      if (user) {
        
      } else {
        
      }
    }}

https://babeljs.io/docs/en/babel-plugin-proposal-do-expressi...

Re: Advice on JSX Conditionals

#33

Post by kingdomcome50 » Wed, Mar 09, 2022, 5:18 PM UTC

TameAntelope wrote: post #26

matt-attack wrote: post #9

Earlier quoted context omitted.

I find ternaries alone to be totally adequate.

Oh they work, but stacking them tends to make future reading of the code harder due to their increased complexity.

Nested ternaries can by structured to look a look like `if/else` if you put the `?/:` in the right spots.

It's a balance. Extracting logic into new components (and often new files!) isn't exactly ergonomic either.

I've found it's better to decrease readability if it makes understanding the logic more straight-forward (i.e. not hunting through several files to exhaust all possible outputs).

Re: Advice on JSX Conditionals

#34

Post by hombre_fatal » Wed, Mar 09, 2022, 5:21 PM UTC

laurent123456 wrote: post #30

I think a better approach is to move the logic to a renderXxx() function: function renderInput(props:Props) { // Early exit if props are not as expected if (!props.cond1) return null; return ; } Then the parent markup is much cleaner, without any conditional: {renderInput(props)}

Though you're also adding indirection.

Not always worth it when you're just trying to do some conditional logic next to the code/components that it's related to.

Ideally we have the tools to decide when to add indirection ourselves instead being forced to do it to deal with complexity. You could also see this in callback-hell when we'd flatten callback trees with indirection—the tree looked flatter in the editor but we just moved code around. async/await gave us the tools to decide when we actually wanted it.

Re: Advice on JSX Conditionals

#35

Post by jkcxn » Wed, Mar 09, 2022, 5:21 PM UTC

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'm happy to pay that cost

Re: Advice on JSX Conditionals

#36

Post by tobr » Wed, Mar 09, 2022, 5:25 PM UTC

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;

Re: Advice on JSX Conditionals

#37

Post by hombre_fatal » Wed, Mar 09, 2022, 5:25 PM UTC

Eric_WVGG wrote: post #16

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

You could of course wrap the switch in a self-invoking function: {() => { switch... }()}

Sometimes an inline switch is indeed the clearest code. The closest JS has is the do-expression proposal: { do { switch... }}

Re: Advice on JSX Conditionals

#38

Post by dimgl » Wed, Mar 09, 2022, 5:28 PM UTC

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;

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.

Re: Advice on JSX Conditionals

#39

Post by threeys » Wed, Mar 09, 2022, 5:30 PM UTC

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

No post body was provided.

Re: Advice on JSX Conditionals

#40

Post by dimgl » Wed, Mar 09, 2022, 5:30 PM UTC

laurent123456 wrote: post #30

I think a better approach is to move the logic to a renderXxx() function: function renderInput(props:Props) { // Early exit if props are not as expected if (!props.cond1) return null; return ; } Then the parent markup is much cleaner, without any conditional: {renderInput(props)}

This pattern is fine, but I would make this a component.

    function ConditionalComponent(props: Props) {
      if (!props.condition) return null
      return 
    }