Hacker News Reader

Comment by amelius | Hacker News Reader

I just read the section "Conditional in JSX", and frankly I think this is crazy. If one needs such inelegant code to deal with basic boolean logic then I'm saying thanks, but no thanks, and I'll use some other tool than React. The section actually speaks of an "alternate hacky approach", which says enough.

View on HN

Conditional-markup solutions always look inelegant.

I'd bet this looks absolutely crazy to many developers:

    <div *ngIf="foo; then bar else baz"></div>

An essentially eval'd code string inside a markup attribute? That uses some made-up language that's neither HTML nor JS?! I used to write plenty of code like this in various template languages, and it always felt bad.

This is best and worst part about Angular. You have this declarative way of rendering parts of a page, but once this gets abused, it becomes a pain in the ass to understand the control flow.

They don't look bad in ClojureScript, IMO.

JS:

   const sampleComponent = () => {
     return isTrue && <p>True!</p>
   };

CLJS:

   (defn sample-component [is-true?]
     (when is-true? [:p "True!"]))

Any language that has if expressions would be preferable to JS in this case, I think.

I don't understand how you'd make a declarative style any more elegant?

  <Conditional bool={true}>
    <IfTrue/>
    <IfFalse/>
  </Conditional>

Doesn't seem any better

The reason OP's complaint is a bit silly is because JSX is just JavaScript and there's no need to be doing everything in a single JSX expression in the first place. That would be bad code just like any other situation. Do what you'd do in normal JavaScript code: use multiple statements and put the conditional elsewhere. Given complicated conditionals, an experienced React dev would do:

    render() {
      let foo
      if (someCondition) {
        foo = <ChildFoo/>
      }
      return (
        <Bar>
          {foo}
        </Bar>
      )
    }

or:

    renderChildFoo() {
      if (someCondition) {
        return <Foo/>
      }
    }
    
    render() {
      return (
        <Bar>
          {this.renderChildFoo()}
        </Bar>
      )
    }

or if possible, always render <Foo/> and conditionally return null in Foo's own render() method.

> JSX is just JavaScript

No, it's not. It's the bastard child of XML and JavaScript. I agree that your examples are about the best you can do with JSX. But actually just JavaScript is much easier:

  render() {
    return Bar(someCondition && Foo())
  }

  render() {
    return Bar(someCondition ? Foo() : null)
  }

That's not quite hyperscript but it's not far from it.

I believe the OP was saying that JSX is transformed into pure javascript, not that it's literally javascript.

Digs at JSX aside, I think you may have lost track of what this thread was about: complicated nested conditionals. These are a pain to do in a single JS expression, JSX or hyperscript or otherwise – even in your example. In JSX your simple example would look just as nice:

    <Bar>{someCondition && <Foo/>}</Bar>

It's not so bad. It's just plain JavaScript conditional logic which any JavaScript developer can understand. It's certainly not worth missing out on the entire framework and ecosystem over this one little thing that you'd get used to doing pretty quickly.

One thing I don't like, though:

  const sampleComponent = () => {
    return isTrue && <p>True!</p>
  };

If isTrue is 0, React will render 0. If isTrue is NaN, React will render NaN. Best to cast the conditional to boolean when using short-circuit evaluation:

  const sampleComponent = () => {
    return !!isTrue && <p>True!</p>
  };

The article’s format is a bit confusing here. I think what you’re reacting to _is_ the “alternate hacky approach”.

Just one line up in the bulleted list is: “Best approach: Move logic to sub-components“. There isn’t an example or a link because the recommendation is that simple.

Of course there are no absolutes and there are many other approaches that split difference between inline logic and additional components, but the general idea is to avoid writing a bunch of conditionals in your JSX unless you have to - and in that case, this mess of nested ternaries is one way to do it.

I think you misunderstand; the article is recommending you don't write the inelegant code or use the "hacky" approach.

> If one needs such inelegant code to deal with basic boolean logic

You don't. Idiomatic React doesn't try and put complex logic in the JSX; the recommended approach (including in the linked article) is to do you logic in plain JS with small focused components or render functions.

It has nothing to do with React, it's just JavaScript. It's no easier or harder to do conditional rendering than any other library I've ever used.

I have written a lot of React and JSX. I have never used that pattern and don't plan to start. I use JS for my conditionals and never put them in JSX. Unless it is a extremely trivial component, I find putting logic inside JSX hard to read and debug.

Agreed. Here's a gist with my preferred approach for writing render methods: https://gist.github.com/markerikson/47fff93c92286db72b22bab5... .

It would look a lot better using proper identation...

    <div>
      {flag && flag2 && !flag3
        ? flag4
        ? <p>Blah</p>
        : flag5
        ? <p>Meh</p>
        : <p>Herp</p>
        : <p>Derp</p>
      }
    </div>

Should be:

    <div>
      { flag && flag2 && !flag3
        ? flag4
            ? <p>Blah</p>
            : flag5
                ? <p>Meh</p>
                : <p>Herp</p>
        : <p>Derp</p>
      }
    </div>

nesting ternaries isnt a thing that should be done

this example should just be using early returns imo

added a PR: https://github.com/vasanthk/react-bits/pull/76/files

You're ditching ALL of React just because one pattern used by some in an optional (JSX) part of the framework? OK then...

The right approach here is really to just do the logic outside of jsx, perhaps as a method on the component or something.

I haven't used React all that much, but this pattern does not seem like it would be common. This seems to be more of a "get something shipped and cut some corners if you need to" scenario.

Is it really that crazy? I'm pretty sure you'd have the same problem with any other language (I.e. most of the popular ones) where if/else isn't an expression.

Reply on news.ycombinator.com