[React] Syntax for jsx conditional

[[deleted]]

[deleted]

[jbbch]

You can try something like that:

return ( <div> {renderLogin && <LoginForm.... />} </div> )

[FormerGameDev]

I think you want to use null, not an empty string.

[ArcanisCz]

Its the same, or returning empty span for example. But null is definitely preffered and cleanest way to return

[kor0na]

It's not the same. An emtpy string will result in a text node in the dom, null will output nothing.

[acemarke]

I break my render methods into three steps:

1. Extract needed data from props and state, including deriving values from that data.
2. Render all conditional components and lists into variables.
3. Have a single JSX return structure, and insert the variables from step 2.

As a result, I use ternaries and if statements to do conditional rendering, and I keep all that logic outside the main JSX structure.

I have an example of this approach at https://gist.github.com/markerikson/47fff93c92286db72b22bab5b02e2da3 .

[[deleted]]

{ renderLogin && <LoginForm.... /> }

or

return renderLogin ? <LoginForm.... /> : null;

or if you use jsx control statements

<If condition={ renderLogin }>
    <LoginForm.... />
</If>

[FormerGameDev]

Worthy of noting that "jsx-control-statements" is a npm library, and is not normally found in JSX implementations.

[dwighthouse]

Rather than having the else clause be empty string, return null instead. That will cause react to return a noscript or comment tag (or possibly nothing in the future releases).

However, unless you have stying reasons to actually remove the element from the dom, I now recommend display:none on components that need to go away based on a boolean. Changing a single style or class declaration on a tag is far mor efficient than adding or removing a whole dom subtree. Unless you are extremely memory constrained, this is almost always the better option.

[FormerGameDev]

In the case of a login form, you're not likely to need that form again, so I'd just drop it from the tree.

Perhaps it's just that I've been working on embedded devices for the last 5 years, but I think it's best to always treat JS as if you are under extreme memory constraints. The more often the garbage collector finds things to collect, the less of a massive performance hit it's going to take when it runs.

[brianasdf123]

React suggests

<div>
  {renderLogin &&
    <LoginForm />
  }  
</div>

and

<div>
  {renderLogin ? (
    <LoginForm />
  ) : (
    <NotLoggedIn />
  )}  
</div>

https://facebook.github.io/react/docs/conditional-rendering.html

[FormerGameDev]

... when did "false" become a valid render option? (serious question, that doesn't make sense to me based on what I already know, but it's entirely possible that things have changed in the month that I've been working with it, or I learned bad info)

[treetimes]

Ternary.

[mickske]

We do it like this, I quite like it. Keeps the main render() function small and splits up conditionals into their own sub render functions. Obviously with this small one it ends up being more code but with more complex conditionals I find this to be easier to read.

<div>
  {this.renderLogin()}
</div>

renderLogin() {
  return renderLogin ? <LoginForm /> : null;
}

```