Proposal: throw syntax error for } and > in JSX text.

[bradzacher]

TypeScript Version: 3.7.x-dev.201xxxxx

Search Terms:
jsx children child

Code

import * as React from 'react';

const a = <div>}</div>;
const b = <div>></div>;

Expected behavior:

Typescript throws a syntax error, as } and > are not valid JSX text characters, as per the JSX spec:

https://facebook.github.io/jsx/

JSXTextCharacter :

• SourceCharacter but not one of {, <, > or }

Actual behavior:

No errors.

Related - typescript errors on { and <, but not because they are invalid characters; it instead errors due to the ambiguity in the syntax and it treating them as an unterminated expression and an incorrect tag respectively.

Playground Link: https://www.typescriptlang.org/play/?jsx=2&ssl=1&ssc=1&pln=5&pc=1#code/JYWwDg9gTgLgBAKjgQwM5wEoFNkGN4BmUEIcA5FDvmQNwBQduEAdqvMnALxwA8AJsABuAPgC+PAPQCR9Jq3gAjLr2nDhk1fSA

Related Issues:
https://github.com/facebook/flow/blob/master/Changelog.md#01160
facebook/flow@e1d0038
babel/babel#11042
acornjs/acorn-jsx#106

I'm bringing this up because flow just made this change, and it seems like a logical one.

Considering it's almost always going to be a UI bug caused due to typos, it seems like a good idea to error on it. Those that want those characters can be explicit and wrap the character as an expression ({'>'}, which is the same thing you do if you want an end of line space).

For reference, this is what now happens when you attempt to parse } or > in flow:

This code:

function F() {
  return <div>></div>;
}

function G() {
  return <div>{1}}</div>;
}

produces the following flow errors:

4:   return <div>></div>;
                 ^ Unexpected token `>`. Did you mean `{'>'}`?
8:   return <div>{1}}</div>;
                    ^ Unexpected token `}`. Did you mean `{'}'}`?

flow.org repl

[RyanCavanaugh]

Catching up to facebook/jsx#18 😉

[RyanCavanaugh]

Well, upon further consideration, this is kind of messed up. It's not an error in Babel, despite this being in the JSX spec for quite a while. I think we'd want Babel (being the de facto "correct" JSX implementation) to issue a syntax error here first so that it doesn't look like we're just making up rules

[bradzacher]

Seems reasonable, I'll look at raising an issue there as well, as I'd love to see this across all implementations.

[bradzacher]

Raised as babel/babel#11042

[bradzacher]

FYI - I'm working on a PR to add this to babel - they would like to get the change in for release with babel 8 (which is due in a few weeks).

[bradzacher]

The PR was just merged into the babel8 branch, so it'll be released with v8.
Additionally there is currently an open PR for acorn.

Off the top of your head, did you have a pointer for where I would go about making this change within the typescript codebase? I'd be happy to raise a PR to make it happen!

[DanielRosenwasser]

src/compiler/parser.ts

Honestly, I'm kind of surprised that with the fact that the implementations all work the way they currently do, that we didn't consider this a spec bug. Is there a good reason we want all these implementations to break people? (i.e. who are we helping?) Should we check with the JSX spec authors?

[RyanCavanaugh]

I think detecting misbalanced } in expressions like <div>{1}}</div> is pretty high-value. When 1 is some complex form, it can be hard to keep track of whether you have the right number of closing }s or not

[bradzacher]

Backstory for how this got implemented in flow:

A dangling } was missed in code review, was shipped to production, and had a bug reported for it.
Annoyed, the engineer quietly wrote a very simple lint rule to catch this (it just checked for } at the start/end of a JSXText node). They shipped it, and manually fixed up a few hundred cases across the facebook codebase.
A few weeks later someone just happened to ask if there was a lint rule they could use for the react native codebase. I mentioned that the lint rule could be synced across, and an engineer on the flow team chimed in saying that they should probably just make it a flow parser error because it's technically invalid JSX.

Fast forward another few weeks and the change was released in flow, and the flow engineer manually fixed up the remaining few hundred errors.

Is there a good reason we want all these implementations to break people?

This is a net benefit for everyone - it's very rare that a dangling } or > is intentional from what I've seen.
You can't include < or { in JSX text anyways, so this just bring parity in for > and }.