-
Notifications
You must be signed in to change notification settings - Fork 131
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
Comments
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 😄 |
@sebmck My tweet inspired by your comment 😄 |
Haha, circle has closed :) (I didn't see the original discussion; sorry @sebmck) |
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. |
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. |
@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 They're also standardized in different order so this could be a process artifact rather than technical rationale. |
What does |
@sebmarkbage Huh, you're right. Everything inside of the |
@sebmarkbage @RReverser That's how arrow functions work too. PS. And having object children seems like something that is rarely useful. |
@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 |
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 Taking the example from the linked tweet in the original post, we can tidy it up through encapsulation as:
We could go a step further and make Menu itself a function-style component, further simplifying the code. |
You need
|
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 expressiondo { ... }
will preserve compatibility and thus wrapping will just enhance contents to support statements as well.@vslinko @sebmarkbage @jeffmo @wycats @sebmck
The text was updated successfully, but these errors were encountered: