RFC: React Expressions with Explicit Generator Expression Semantics

[clemmy]

RFC: React Expressions with Explicit Generator Expression Semantics

For more background on this proposal, please refer to #98.
In that thread, there was a lot of backlash for the implicit nature of the do-generator by unifying it with the current {} JSX expression syntax. This proposal makes it explicit by using the *{...} syntax for generator expressions. So all the old goodies will be kept:

<div>{ items.map(i => <li key={i.key} />) }</div> // expression

<div style={{ position: 'absolute' }} /> // object literal

// these still work!

But more adventurous users will be able to use the following syntax for generator expressions:

<div>*{ for (let item of items) yield item; }</div>
// loops!

The Generator Expressions proposal is here: https://github.com/sebmarkbage/ecmascript-generator-expression.

Try it out (CodePen Examples)

• early break
• odd/even
• nested loops
• fibonacci

Caveats

Strings in JSXText with a * immediately before a left brace will be parsed as a JSXGeneratorExpression.

<div>
  This is a paragraph* with some asterisk.
  *{explanation}
</div>

[sebmarkbage]

We'll need a disambiguator in JSXText for * {. For example, you can exclude * from JSXTextCharacter and explicitly allow it in JSXText for certain contexts. E.g. by a look ahead.

Note that JSXGeneratorExpressionContainer is defined in terms of two token so spaces, comments etc. are allowed between. E.g. this is still a generator:

<div>* /* hello */ { yield 1; }</div>

[sebmarkbage]

FunctionBody is ambiguous since it also includes BlockStatement, FunctionDeclaration, ClassDeclaration, GeneratorExpression and AsyncFunctionDeclaration.

We need to exclude them from the list. Either by defining our own statement list explicitly, or by excluding these by some kind of lookahead.

E.g. an explicit list could look something like this:

JSXStatementList:
  JSXStatementListFirstItem StatementList[opt]

JSXStatementListFirstItem:
  LexicalDeclaration
  VariableStatement
  ExpressionStatement
  IfStatement
  BreakableStatement
  BreakStatement
  WithStatement
  LabelledStatement
  ThrowStatement
  TryStatement
  DebuggerStatement

(This also highlights the maintenance cost associated with forking the language.)

[clemmy]

Ah I see, this is a problem with the other proposal as well, and I'm not sure there's a way to lower the maintenance cost by a significant amount. Either way, we'll need to keep adding to lookaheads or JSXStatementListFirstItem for new ECMAScript features. For now I'll just go with the lookahead approach - we just can't have {, class, async, function, and do right?

[clemmy]

Wondering what to do for (...