Support for other JSX factories

[rwyborn]

PR for Issue #3788

Current implementation adds a new jsxNamespace compile option that can specify the JSX namespace (factory) when jsx mode is react.

--jsx react --jsxNamespace MyDOMLib

results in emits being MyDOMLib.createElement

I was thinking an alternative would be to just use the existing --jsx option where "preserve" and "react" are special reserved values. In this setup the above would be achieved by just doing

-- jsx MyDOMLib

[msftclas]

Hi @rwyborn, I'm your friendly neighborhood Microsoft Pull Request Bot (You can call me MSBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!

The agreement was validated by Microsoft and real humans are currently evaluating your PR.

TTYL, MSBOT;

[RyanCavanaugh]

I think we need to tweak the naming a bit here. This change is still very useful but doesn't directly address #3788 because it still requires that the library have the same shape (.createElement) as React.

I'm thinking:

let x = <Foo />;

• --jsx preserve
  • let x = <Foo />;
• --jsx react
  • let x = React.createElement(Foo);
• --jsx react --reactNamespace rt
  • let x = rt.createElement(Foo);
• --jsx make
  • let x = make(Foo);

[DanielRosenwasser]

If you have --jsx make, why exactly do you need --reactNamespace rt?

[unional]

I would suggest to "pollute the global" with a meaningful namespace, such as JSX.make() or JSX.compose(). But simple make() might work too, just that it is a bit less convenience when I customize it in code (i.e. couldn't have a proper singleton such as JSX to hold states, when needed).

[rwyborn]

@RyanCavanaugh I had exactly the same thought originally re: your --jsx make example. The problem is this doesn't define what to do with the JSX spread handling, which emits a call to React.__spread. So my compromise was to let the namespace be configured instead, ie --jsxNamespace MyDOMHandler emits

• MyDOMHandler.createElement
• MyDOMHandler.__spread

Client code can then map those to whatever custom library implementation it wants.

[tinganho]

Namespace for me, means only MyDOMHandler and not with the method name MyDOMHandler.createElement. createElement is occupying the namespace of MyDOMHandler so itself is not a namespace IMO.

What about?

--react for preserving current behavior of --jsx react.
--jsxElementFactory [value] for defining the factory function for JSX.

I think the option --jsx was a little bit ambiguous. And since --jsx preserve doesn't make so much sense anymore when this got landed maybe deprecate --jsx option?

[RyanCavanaugh]

Sorry for the delay.

Discussed with @billti and @mhegazy and we landed on the following

• This PR is 👍 (see one comment below)
• More complex changes to emit semantics will wait until @rbuckton tree-transform-based emitter is checked in. At that point we can re-evaluate (e.g. we may end up with fully-pluggable JSX transforms)

The only change I'd like to see here (other than removal of merge conflicts 😉) is that jsxNamespace should be reactNamepsace since this is specific to React emit (and I don't want confusion with the real namespace JSX { which is not changing names).

Thanks!

[mhegazy]

@rwyborn please change the option name to reactNamespace and refresh the PR, and we should be good to go.

[mhegazy]

merged manually after updating the name and adding tests.

[mhegazy]

thanks @rwyborn!

[rwyborn]

@mhegazy I just got back from holiday, thanks for fixing this up!

[unional]

More complex changes to emit semantics will wait until @rbuckton tree-transform-based emitter is checked in. At that point we can re-evaluate (e.g. we may end up with fully-pluggable JSX transforms)

How is that doing?
It is this one? #6987

[mhegazy]

@unional looks like you are looking for #12135

[unional]

Thank! I'll take a look at it.

It's been a while ago, I need to refresh what is my original needs. 🌷