feat: JSX Support

[keroxp]

PR for #3037

Added JSX support feature. Now .jsx .tsx files can be imported.
By default, there is no jsxFactory function at runtime. Default jsxFactory value of tsconfig.json is React.createElement. To use jsx/tsx in Deno, define or import react before JSX expression or define your own React.createElement or use custom jsxFactory with tsconfig.json:

import React from "https://dev.jspm.io/react"
import ReactDOMServer from "https://dev.jspm.io/react-dom/server"
const str = ReactDOMServer.renderToString(<div className="deno">land</div>);
console.log(str);
// => <div class="deno" data-reactroot="">land</div>

[ry]

@keroxp JSX support is desirable - but is it necessary to add these top level methods to Deno? renderToString, Component, etc... Those seem like framework level needs.

Also, please add an integration test to cli/tests/integration_tests.rs

[keroxp]

@ry Not necessary but may be convenient for developers. Ok I'll remove default jsx factories from this PR anyway.

[kitsonk]

Not linted properly. We should ensure the linting covers these files as well.

[kitsonk]

I am concerned we are not using the default here of React.createElement. I can understand why, but it will be potentially surprising to users that we aren't using the default. At the very least I would like to see updates to the manual along with this PR before we merge it explaining how it is anticipated to be used.

[keroxp]

I think either is OK. React.creaetElement may rather be useful for real use. react and react-dom/server can be imported in Deno via dev.jspm.io.

[kitsonk]

Are you sure about this. This will leave the .jsx untouched if the checkJs compiler flag is not set. I can't see that being desirable.

We should have tests around .jsx and we should have an expected behaviour of how they are handled. We also need it consistent with how the compiler behaves, where by default we have allow JS but not check JS, so how does that effect the emit?

[keroxp]

Oh, I absolutely forgot it. Hmm... should we compile .jsx files as TSX?

[kitsonk]

Well, not compile as TSX, more that we will always attempt to transpile them, move it to the previous match clause, but I would check that that works as expected, when the checkJs compiler flag is not enabled (which is the default), which the integration test should prove.

[keroxp]

@ry Added integration tests for jsx / tsx file. Both will be compiled same as ts and changed default jsxFactory to React.createElement . So can you check it?

[ry]

LGTM - i look forward to doing react in deno

[PopovMP]

JSX was the last thing I expected in Deno core. Highly disappointed (((
So we discard NPM but include React. Probably the next will be $ or Vue or Laravel...
I was looking at Deno as a new pure tool without any bad legacy.

Wish you luck!
unfollow

[ry]

@PopovMP Deno doesn't include React - JSX support is part of the TypeScript compiler - this is just exposing that feature. If you notice this PR only added 61 lines (which is mostly the integration tests).

[GrosSacASac]

Does it increase compile time for non-JSX files as well ?

[ry]

@GrosSacASac No - we did not observe any change in our compile time benchmarks.

[kitsonk]

@GrosSacASac it basically allowed something through that we didn't allow before. The capability has always been there in the TypeScript compiler, basically all that needed to be done was to interpret the media types properly.

While this feature doesn't make sense in and of itself for server side workloads, it does in the context of server side rendering. Of course end users could load a transpiler for JSX/TSX in the runtime and deal with all the module resolution, or we could just enable a feature already there. It makes sense to do the latter. I personally strongly dislike JSX, but it would be stilly to specifically hobble the compiler support to enforce that opinion on others.

We plan to support a public compiler API (see: #1739) and that would have allowed people to support it directly in Deno anyways, though some sort of custom compiler. Again it would be silly to force users to do that when it is already natively supported.