3 ms·

Huh, that's really interesting, the Firefox dev tools even do proper syntax highlighting. I wonder how JSX parsers react to this. A quick test with an online Ba

Huh, that's really interesting, the Firefox dev tools even do proper syntax highlighting. I wonder how JSX parsers react to this. A quick test with an online Babel parser is throwing errors, so I assume it's just not supported? But maybe there's a setting. JSX also by default doesn't have an easy way to insert comments into the generated HTML, so I don't think JSX is the reason why it wouldn't be supported in Babel. My understanding was always that it has more to do with comments being treated slightly differently than normal document nodes, but I could be wrong. I guess more likely the reasoning is that it's just obscure. I've been programming JS for a reasonably long time and never knew this was supported.

colejohnson66 5y ago
The reason for the error from Babel is that JSX is an HTML like (more so XML) syntax, not HTML. The obtuse comment syntax is because you need to escape to JavaScript with the braces, then use a multi-line JavaScript comment block. I wish they would've allowed HTML comments in the original design, but my guess is that comments were an oversight that just happened to work due to the escape syntax.
- schwartzworld 5y ago
  It shouldn't be hard to create a component that does what you want <Comment>some comment</Comment>
  - deleted 5y ago
    [deleted]
- chrismorgan 5y ago
  One good reason not to support it is that it’s ambiguous: is it a comment (to be ignored), or does it represent a comment node? If the former, why not just use /…/? If the latter, it requires that the library or compilation target or whatever support comment nodes, which is more work for a dubious feature.
  - colejohnson66 5y ago
    I'd argue that comments only serve to help the developer. And when using JSX, the generated HTML might not look pretty (such as being a single, long line). So an HTML style comment in the JSX should be stripped because debugging the minified HTML isn't something people generally do. And if, for some reason, you wanted to inject an HTML comment into the output, you could abuse the `dangerouslySetInnerHTML` prop like this: function Comment(props) { return <span dangerouslySetInnerHTML={{__html: `` }} />; } Then use it like this: ... <Comment comment="my comment" /> ... Using `React.Fragment` doesn't work, sadly. Use the "Inspect Element" tool on the output here: https://playcode.io/870223 https://playcode.io/870223
    - eyelidlessness 5y ago
      There are other use cases for (preserved) HTML comments in (or produced by) JSX, but generally more for library authors than end users. For example, comments can be used for hydration markers to delineate “hydration islands” without need for a wrapping element. (I have a proof of concept of this sitting in a Codepen somewhere.) And while it doesn’t work in React’s Fragment, it can certainly work with another compiler. JSX doesn’t specify anything about what it compiles to, React.createElement/_jsx are just defaults.
chrismorgan 5y ago
A challenge: figure out how to get to the script data double escaped state (https://html.spec.whatwg.org/multipage/parsing.html#script-data-double-escaped-state https://html.spec.whatwg.org/multipage/parsing.html#script-d...), or perhaps cheat by looking at https://stackoverflow.com/questions/23727025/script-double-escaped-state https://stackoverflow.com/questions/23727025/script-double-e.... Then, contemplate the implications, and devise an injection attack for something that is foolish enough to try to emit anything user-controllable into JavaScript (suppose it’s a string: they may have thought it was enough to escape \ and ", but this will rapidly show you that it’s not). Reading through the specs reveals lots of curious historical details. The HTML spec is a glorious tangled mess because it’s an exhaustive definition of a large amount of functionality that grew⸺ ah⸺ organically.
bradneuberg 5y ago
I’ve literally been programming in JS for more than 20 years and this is new to me too!
eMSF 5y ago
The syntax highlighting in Fx dev tools has the same mistake as the article in that they only recognize the "close comment" token if it's at the beginning of the line, even though the spec clearly states that it may be preceded by any number of single-line "multiline" comments on the same line. However, the way I understand the spec, you shouldn't be able to start a line comment with `-->' after an actual multi-line comment (i.e. a delimited comment that contains line terminators); however, both Firefox and Chrome seem to disagree with my interpretation; for example i = 1; while (i /* */ --> 0 ) console.log(i); // this loop never terminates

colejohnson66 5y ago

The reason for the error from Babel is that JSX is an HTML like (more so XML) syntax, not HTML. The obtuse comment syntax is because you need to escape to JavaScript with the braces, then use a multi-line JavaScript comment block. I wish they would've allowed HTML comments in the original design, but my guess is that comments were an oversight that just happened to work due to the escape syntax.

schwartzworld 5y ago
It shouldn't be hard to create a component that does what you want <Comment>some comment</Comment>
- deleted 5y ago
  [deleted]
chrismorgan 5y ago
One good reason not to support it is that it’s ambiguous: is it a comment (to be ignored), or does it represent a comment node? If the former, why not just use /…/? If the latter, it requires that the library or compilation target or whatever support comment nodes, which is more work for a dubious feature.
- colejohnson66 5y ago
  I'd argue that comments only serve to help the developer. And when using JSX, the generated HTML might not look pretty (such as being a single, long line). So an HTML style comment in the JSX should be stripped because debugging the minified HTML isn't something people generally do. And if, for some reason, you wanted to inject an HTML comment into the output, you could abuse the `dangerouslySetInnerHTML` prop like this: function Comment(props) { return <span dangerouslySetInnerHTML={{__html: `` }} />; } Then use it like this: ... <Comment comment="my comment" /> ... Using `React.Fragment` doesn't work, sadly. Use the "Inspect Element" tool on the output here: https://playcode.io/870223 https://playcode.io/870223
  - eyelidlessness 5y ago
    There are other use cases for (preserved) HTML comments in (or produced by) JSX, but generally more for library authors than end users. For example, comments can be used for hydration markers to delineate “hydration islands” without need for a wrapping element. (I have a proof of concept of this sitting in a Codepen somewhere.) And while it doesn’t work in React’s Fragment, it can certainly work with another compiler. JSX doesn’t specify anything about what it compiles to, React.createElement/_jsx are just defaults.

chrismorgan 5y ago

A challenge: figure out how to get to the script data double escaped state (https://html.spec.whatwg.org/multipage/parsing.html#script-data-double-escaped-state https://html.spec.whatwg.org/multipage/parsing.html#script-d...), or perhaps cheat by looking at https://stackoverflow.com/questions/23727025/script-double-escaped-state https://stackoverflow.com/questions/23727025/script-double-e.... Then, contemplate the implications, and devise an injection attack for something that is foolish enough to try to emit anything user-controllable into JavaScript (suppose it’s a string: they may have thought it was enough to escape \ and ", but this will rapidly show you that it’s not). Reading through the specs reveals lots of curious historical details. The HTML spec is a glorious tangled mess because it’s an exhaustive definition of a large amount of functionality that grew⸺ ah⸺ organically.

bradneuberg 5y ago

I’ve literally been programming in JS for more than 20 years and this is new to me too!

eMSF 5y ago

The syntax highlighting in Fx dev tools has the same mistake as the article in that they only recognize the "close comment" token if it's at the beginning of the line, even though the spec clearly states that it may be preceded by any number of single-line "multiline" comments on the same line. However, the way I understand the spec, you shouldn't be able to start a line comment with `-->' after an actual multi-line comment (i.e. a delimited comment that contains line terminators); however, both Firefox and Chrome seem to disagree with my interpretation; for example i = 1; while (i /* */ --> 0 ) console.log(i); // this loop never terminates