Repository navigation
Proposal: throw syntax error for } and > in JSX text. #36341
Description
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.
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 `{'}'}`?
Activity
RyanCavanaugh commentedon Jan 21, 2020
Catching up to react/jsx#18 😉
RyanCavanaugh commentedon Jan 21, 2020
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 commentedon Jan 22, 2020
Seems reasonable, I'll look at raising an issue there as well, as I'd love to see this across all implementations.
bradzacher commentedon Jan 22, 2020
Raised as babel/babel#11042
bradzacher commentedon Jan 23, 2020
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 commentedon Feb 5, 2020
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 commentedon Feb 5, 2020
src/compiler/parser.tsHonestly, 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 commentedon Feb 5, 2020
I think detecting misbalanced
}in expressions like<div>{1}}</div>is pretty high-value. When1is some complex form, it can be hard to keep track of whether you have the right number of closing}s or notbradzacher commentedon Feb 5, 2020
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.
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}.Throw syntax error for `}` and `>` in JSX text (#36636)