Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: implicitly use do-expression for any JSX expr container #39

Open
RReverser opened this issue Jul 10, 2015 · 13 comments
Open

Proposal: implicitly use do-expression for any JSX expr container #39

RReverser opened this issue Jul 10, 2015 · 13 comments
Labels
Proposal Proposals (haven't confirmed)

Comments

@RReverser
Copy link
Contributor

I just saw this tweet: https://twitter.com/vslinko/status/619581969903550464

And wondering if there are any downsides or backward incompatibilities to enabling do-expression over any JSX expression container so that if and other statements could be used directly inside of braces? My understanding is that for regular expression do { ... } will preserve compatibility and thus wrapping will just enhance contents to support statements as well.

@vslinko @sebmarkbage @jeffmo @wycats @sebmck

@sebmck
Copy link

sebmck commented Jul 10, 2015

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
Copy link

vslinko commented Jul 10, 2015

@sebmck My tweet inspired by your comment 😄

@RReverser
Copy link
Contributor Author

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

@syranide
Copy link
Contributor

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.

@sebmarkbage
Copy link
Contributor

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
Copy link
Contributor

@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
Copy link
Contributor

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 {({ })}.

@RReverser
Copy link
Contributor Author

@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
Copy link
Contributor

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

@RReverser
Copy link
Contributor Author

@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.

@ghost
Copy link

ghost commented Jan 3, 2018

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.

@graingert
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposal Proposals (haven't confirmed)
Projects
None yet
Development

No branches or pull requests

8 participants