Proposal: implicitly use do-expression for any JSX expr container about jsx

[sebmarkbage]

To follow up. This is still an open issue, but not very high priority until do expressions are further along the standardization track and its semantics clarified.

[sebmarkbage]

@syranide I'm not sure it is obviously so. Would you care to elaborate? Do you mean fat-arrows with the block or single expression? Regardless, fat-arrows don't do this.

I think the rationale may be different since it is a late executing block. For example, control flow like return, break, continue... behaves very differently in these cases.

They're also standardized in different order so this could be a process artifact rather than technical rationale.

[sebmarkbage]

What does {x:1} mean in a do expression body? Is it a block with a label or an object literal? If it's a block, it is unfortunate that {{ }} wouldn't work to create an object. You would have to use {({ })}.

[graingert]

{foo && <bar foo={foo} />} is buggy, if foo is undefined then React will warn.

You need {foo && <bar foo={foo} /> || null} in which case you might as well use ternary:

{foo ? <bar foo={foo} /> : null}

[chicoxyzzy]

ref https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-01/jan-29.md#do-expression

[sebmck]

I can implement this in Babel with literally a few lines so 👍 from me. Also see reactjs/react-future#35 which is the exact issue that prompted that tweet and discussion 😄

[vslinko]

@sebmck My tweet inspired by your comment 😄

[RReverser]

Haha, circle has closed :) (I didn't see the original discussion; sorry @sebmck)

[syranide]

My main objection would be that if this makes sense... then it should make sense for fat-arrow functions as well, if they choose not to have it JSX probably shouldn't either.

[RReverser]

@sebmarkbage Huh, you're right. Everything inside of the do expression, incl. {x:1} is a block. Might be a serious issue for us.

[syranide]

@sebmarkbage @RReverser That's how arrow functions work too. PS. And having object children seems like something that is rarely useful.

[RReverser]

@syranide I still fail to see why you compare arrow functions to do expressions. They were designed as functions after all, so they had to be able to provide code blocks that don't return any values but behave pretty much as regular functions/blocks. Do expressions are different in the sense that their entire point is exactly to implicitly return last value. Arrow functions don't need to adopt this implicit behavior by default, but do expressions complement them in the sense that you can do x => do { ... } when it's needed.

This seems like a good idea at first glance but I'm concerned it encourages spaghetti code.

I can't think of a use case that couldn't already be implemented in a better way, predominantly through encapsulation. In simple cases bool expressions are fine (the classic {foo && <bar foo={foo} />}), in more complicated cases encapsulation provides cleaner code and better reusability (for better or worse).

Taking the example from the linked tweet in the original post, we can tidy it up through encapsulation as:

function UserMenuItem(props) {
  return props.user ? <UserInfo user={user} /> : <LoginForm />;
}

class Menu {
  render() {
    return <div>
      <h2>Menu</h2>
      <UserMenuItem user={this.props.user} />
    </div>;
  }
}

We could go a step further and make Menu itself a function-style component, further simplifying the code.