Use do { } makes React render() method more readable

do notation.js

// FP languages permit to evaluate if/else expressions as values.
// In many cases it permits to avoid using mutable variables (var/let), multiple returns, or nested ternary operators

// This is the do { } notation (stage 0), that permits to write the following right now with Babel.

const Users = ({users}) =>   (
  <div>
    {users.map(user =>
      <UserCard key={user.id} user={user}/>
    )}
  </div>
)  

const UserList = ({users}) => do {
  if (!users) <div>Loading</div>
  else if (!users.length) <div>Empty</div>
  else <Users users={users}/>
}

Babel repl link to try: here

Why not

const UserList = ({users}) => 
  !users ? <div>Loading</div> :
  !users.length ? <div>Empty</div> :
  <Users users={users}/>

why new sintax?

maybe there are examples where this sintax is useful but I don't think this is one of them.

It's not a hate comment. It's a genuine question. I re-read it an it may pass on as just trying to get you down. Sorry for that

nice, I like the do version, for me if/else statements are more readable :)

@pitermarx in this case I'd say the ternary operator is enough (however I still think the do version a little bit more readable). I think it's more easy to write a statement that is human-readable (DSL-like) when there are clear words to express branching.

A if/else statement can be understood easily by business people as it is much closer to human language you would use to describe the flow, while it would probably not be the case for ternary flow. Ternary are readable if you are used to them, but even if you are used to them I'd bet that on a reading code contest people would perform better at reading if/else than ternary (even if using a lot of ternary ops)

Honnestly I tend to avoid using ternary operators because it can become hard to read on more complex cases where there is more branching/nesting. But in my own code I'll probably hesitate between if/else and ternary for such an example, as do notation is not stable enough and in this case the if/else is too much verbose

I'm not sure this is the best example. @pitermarx showed a way to do this without need of that new feature.
However, I do think it's pretty interesting for any time you want to calculate something that requires intermediary computation and you don't want to pollute the outside scope.

It's something not far from an auto-called function but without need to use return.

I also like the implicit return value. This is something we didn't have in JavaScript but which exists in other languages like scala (returned value of a block, is evaluated from the last expression).

I was a bit concerned by a potential syntax ambiguity. like imagine if you use while(test) on the next line. But actually, that new do{} is an expression that only is syntax valid if you use its value. if you don't use the returned value, THEN it's the do{}while(test) loop. so there is no ambiguity (as far I as understood. please discuss if i'm wrong)

Also one question: is there a way this can work with switch?! (instead of if)
I don't seem to be able to do this.

@gre I agree with you and often use code-blocks in scala to limit the scope of unnecessary variables.

I'm not sure it can work with switch because in switch it's not like pattern matching, and you can enter on multiple "branches" if you don't use break/return. Inside do {}, if you don't use return on switch it... does not return anything. If you put a return it says you are not in a function context so can't return.

I guess what you want is this in a more idiomatic way? I'd also love that

const CodeBlockResult = (() => {
  const someEnum = "case1";
  switch (someEnum) {
    case "case1": return "val1";
    case "case2": return "val2"
    case "case3": return "val3"
    default: return "val4"
  }
})();

Isn't it annoying to have to use let reassignment with switch, or this weird function syntax ? :)

can't wait pattern matching :D