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.

Sign up for GitHub

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

RFC: React Expressions with Implicit Do-Generator Semantics #98

Closed
wants to merge 3 commits into from
+21 −10
Closed

RFC: React Expressions with Implicit Do-Generator Semantics #98

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
38b4965
Update spec with jsx generation expressions
Nov 7, 2017
8747532
Add suggested changes to spec for JSX Generator Expressions
Nov 9, 2017
eeb2364
Update AST.md
clemmy Nov 9, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 4 additions & 11 deletions AST.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -39,20 +39,13 @@ interface JSXNamespacedName <: Expression {
JSX Expression Container
------------------------

JSX adds empty "expression" type in order to allow comments in JSX text:
The expression container node contains statements with the same grammar as a generator body. Also it has a flag to indicate if a yield is present in the body. Any expression used as attribute value or inside JSX text should is wrapped into expression container:

```js
interface JSXEmptyExpression <: Node {
type: "JSXEmptyExpression";
}
```

Any expression used as attribute value or inside JSX text should is wrapped into expression container:

```js
interface JSXExpressionContainer <: Node {
interface JSXExpressionContainer <: Expression {
type: "JSXExpressionContainer";
expression: Expression | JSXEmptyExpression;
statements: [ Statement | Declaration ];
Copy link
Contributor

@sebmarkbage sebmarkbage Nov 7, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Declaration is a Statement in ESTree terminology (unlike the ES spec). Specifying both is superfluous.

We should probably go for backwards compatibility here. Lots of people can have transforms, linters and other things that depend on this.

We could have a flag that switches between the statement list form or expression form depending on if there are more than one expression. Similar to how ArrowFunctionExpression works.

hasYield: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a requirement? Seems like the transform could figure that out if needed. I suppose it makes transform order and such a bit easier to deal with but for Babel I think it should be fine to visit the tree on demand.

It's probably helpful to have though. We can just call it generator then since arrow function has that flag. Later we could add async as well if there's an await.

}
```

Expand Down
14 changes: 10 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@ PrimaryExpression :

- JSXElement
- JSXFragment
- JSXGeneratorExpression

__Elements__

Expand Down Expand Up @@ -95,7 +96,7 @@ JSXAttributes :


JSXSpreadAttribute :

- `{` `...` AssignmentExpression `}`
- `{` `...` JSXGeneratorExpression `}`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't really work. You can't have a spread beginning a sequence of statements. I think for spread we'll need to leave it as AssignmentExpression. (Although it is really weird that this can be a SequenceExpression.)

Same thing in JSXChildExpression.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it was a bit odd to define JSXGeneratorExpression as a StatementList, but rather I should define it with the surround braces: { StatementList }?


JSXAttribute :


Expand All @@ -114,10 +115,15 @@ JSXAttributeValue :


- `"` JSXDoubleStringCharacters<sub>opt</sub> `"`
- `'` JSXSingleStringCharacters<sub>opt</sub> `'`
- `{` AssignmentExpression `}`
- `{` JSXGeneratorExpression `}`
- JSXElement
- JSXFragment

JSXGeneratorExpression :

- [lookahead &#8712; { `{` }] ObjectLiteral
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This checks for equality, which is unnecessary since ObjectLiteral will require it, but it also leaves it ambiguous because it'll match both branches.

Instead, use a negative lookahead on the StatementList below.

- StatementList<sub>[+Yield]</sub>

JSXDoubleStringCharacters :


- JSXDoubleStringCharacter JSXDoubleStringCharacters<sub>opt</sub>
Expand Down Expand Up @@ -157,8 +163,8 @@ JSXTextCharacter :

JSXChildExpression :

- AssignmentExpression
- `...` AssignmentExpression
- JSXGeneratorExpression
- `...` JSXGeneratorExpression

__Whitespace and Comments__

Expand Down