RFC: An evolved JSX 2.0 proposal

[nojvek]

I acknowledge that the old JSX 2.0 proposal (#65) had way too many comments to keep up a discussion and is closed for discussion.

This proposal tries to accomodate many existing issues. It is based on the existing JSX 2.0 proposal by @sebmarkbage.

Guiding principles

1. Simpler and closer to existing JavaScript syntax. JSX is an extension of Javascript.
2. Incorporate less of the html quirks.

What this proposal isn't

1. No special behavior for control structures like if, else e.g special behavior for <If> tags. JSX semantics should only focus on expressing the tree structure of tags and expressions. The logic structure should be dictated by existing JS syntax e.g ternary x ? y : z and someArray.map to iterate over arrays. When do expressions make it to ES spec, they can focus on more expressive logic semantics.

2. Concerned with how jsx gets transpiled and emitted. This proposal purely focuses on syntax. i.e no special syntax for event handler binding.

• Proposal: Namespaces for passing nested data structures #81 namespaces for passing nested objects (jsx already supports namespaces) - this is emit level behavior
• can you provide a syntactic sugar? #122 syntatic sugar for bind
• Special syntax for child functions #104 special sugar for child functions

Issues taken into consideration

The proposal purely focuses on parser level semantics

#4 - Drop HTML encoding in text and attributes.
#21 - Computed attribute names.
#23 - Object short hand notation.
#25, #51, #64 - Drop the need for curlies around attribute values if they're a single literal, or parenthesis.
#35, #8 - Crazy Idea: Deprecate JSXText?
#68 - Make JSX even more like JS
#7 - Comments in JSXElement
#117 - non-breaking changes for attribute values
#108 - Computed attribute names
#103 - Curly braces for attribute expressions are pointless and ugly
#76 - Destructuring
#53 - Remove JSXElement from JSXAttributeValue production

The major breaking changes to existing spec

1. Parens to specify expressions like JS instead of curly braces e.g {...} -> (...)
2. JSXChildren are either JSXElements, ParensExpression or Literals.
3. There is no JSXText. No special entity encoding or implicit whitespace to deal with.

JSX Elements

JSXElement remains as is. No changes here.

• JSXOpeningElement JSXClosingElement - <div></div>
• JSXSelfClosingElement - </br/>
• JSXMemberExpression - <Context.Provider></Context.Provider> -
• JSXNamespacedName - <hello:world></hello:world>
• JSXFragmentElement -<> </>

JSXAttribute

• Shorthand - <div x y> evaluated like JS object shorthand as <div x=x y=y, instead of current behavior <div x=true y=true>. Maps to JS object syntax: jsx('div', {x, y}).
• Spread - <div ...props> instead of current div {...props}. Maps to JS object syntax: jsx('div', {...props})
• Computed - <div ['hello' + 2]='world'>. Maps to JS object syntax jsx('div', {['hello' + 2]: 'world'})
• In essence x=y maps to {x:y} in JS object syntax.

JSXAttributeValue

• Literal - x="hello", x='hello', x=2, x=true, x=null
• TemplateLiteral - x=`some ${value}`
• Identifier - x=foo_ba$r23
• ParensExpression - x=(1+2), x=({key: val}), x=(<div/>)
• JSXFragment - Removed: Use x=(<></>) instead of x=<></>
• JSXElement - Removed: Use x=(<div/>) instead of x=<div/>. Typescript to-date hasn't support this production. It's support is lacking amongst diffent tools and is needlesly complex. It can be echieved with just two extra characters. See Remove JSXElement from JSXAttributeValue production? #53

ParensExpression: (expr) replaces {expr} as expression syntax since JS already understands (...). For x={{hello:world}}, { has double meaning. The first use is to signify expression, and the next use is the object initializer.

x=((((((1)))))) still means an expression, no matter how many parentheses.

JSXChild

• JSXElement | JSXFragment - No changes
• JSXText - Removed. Have to use explicit strings instead e.g <div>"Hello World"</div>. Whitespace can be explicitly noted e.g <div> " Hello World " </div>
• Literal | TemplateLiteral | Identifier - <div> 1 foobar true null "SomeStr" `Hello ${world}`</div>. Any space separated literals work.
• ParensExpression - <div>(user.isLoggedIn() > 0 ? <Login/> : <Home/>)</div> - Replaces {} as the expression with ()
• SingleLineComment | MultilineComment - // or /* */

Complex Example:

<div>
  (users.map(user => 
    <>
      <User user/>
      " "
      (user.isPro() ? "Pro" : "Free")
    </>
  ))
  <span style=({fontWeight: 400})>`There are`</span>
  `${users.length} `
  (users.length == 1 ? "User" : "Users")

  <script>
    // We can have single line comments
    /* or 
     * multiline comments like JS
     */
    `
    multiline text body can contain all sorts of weird characters <>&"'¢£¥€©®

    including new lines with ${user.name} expressions
    `
  </script>
</div>

[nojvek]

@sebmarkbage / @RyanCavanaugh just wondering if you have any opinions ^

I wonder who else needs to be pinged to have a serious discussion of pros/cons and viability.

A part of me wants to create a typescript prototype with “jsxVersion: 2” compiler flag.