Support other JSX factories

[tinganho]

Seems like Babel supports other JSX factories other than React.createElement(...):

Here is docs from deku another JSX framework from Segment.io
Using .babelrc:

{
  "jsxPragma": "element"
}

Source: https://github.com/dekujs/deku/blob/master/docs/guides/jsx.md#babelrc

I propose we add something similar to the TS compiler options. Letting people to do a post build of preserved JSX element is not the nicest solution.

[tinganho]

To be more specific about JSX factories, I mean React.createElement is switched with whatever specified factory function. All the other rewires like attributes etc. remains the same. So I guess this is a small change.

PS. Also the jsx-transform supports other factory functions: https://github.com/alexmingoia/jsx-transform

[tinganho]

What's the status of this?

I'm creating right now a JSX framework. Though I'm using a dirty trick with reusing React's namespaces.

[RyanCavanaugh]

I think we're mostly waiting for feedback. There have been some other JSX emit suggestions and we'll need to prioritize based on how necessary (un-work-around-able) and useful they are.

[mindplay-dk]

Yeah, I am really excited about this feature and was trying it out with MS Code tonight - but then realized, two options for JSX processing, one just passes through JSX tags unprocessed, and the other is hard-wired to React... I don't want React - I want something lightweight. Like, for one, I was hoping maybe riotjs could be supported. Moreover, I don't want to be tied to any particular implementation.

Sounds like you're already aware of that though? :-)

How about providing a compiler (and tsconfig.json) switch that allows you to specify which implementation to use?

It's already type-checking against an interface, right?

So, if this interface was defined by Typescript, rather than defined by an external React.d.ts file, we could then implement this interface, specify the name of the implementation, and have the compiler type-check against an implementation of our choice?

Emit would be largely the same then, I think? Just with XYZ. instead of React. and type-checking against the specified implementation.

I think per-project (e.g. compiler-level) is fine, and much simpler than e.g. allowing you to somehow switch implementations on a per-file basis or something - I don't imagine you'd need/want to use more than one implementation in the same project (?)

I'm really excited about this feature!

Hope is arrives in a form that is also useful to non-Reacters. (Reactionist? Reactioners? Whatever.)

[mhegazy]

Type checking is not tied to any framework; type checking is driven by JSX namepsace declaration (see wiki page for more details).

Emitting with -jsx preserve will result in emitting your jsx into the output after transforming any TS specific concepts, e.g. internal modules, rewriting let and const, module imports, etc..

Any JSX library out there already has a compiler that supports transpiling jsx into their supported output. riotjs as well provides a compiler. the integration scenarios with TS is straight forward and with a very low over head.

For maintenance reasons, the typescript team would not want to take on the responsibility of emitting to multiple frameworks. we do care that these scenarios do work though, and the --jsx preserve is mainly for this.

[mindplay-dk]

Type checking is not tied to any framework; type checking is driven by JSX namepsace declaration

Alright, so we're half-way there :-)

For maintenance reasons, the typescript team would not want to take on the responsibility of emitting to multiple frameworks

That's not really what I'm asking for - literally all I'm asking is for, is to avoid the extra compile step in a second compiler, by allowing us to replace the emitted React. with something else. Why does that add any maintenance burden on your part?

I'd really like to avoid relying on a second compiler/tool - for one, how would that work in terms of source maps? You'd need to recursively resolve source-maps from one compiler via source-maps from another compiler? Or the second compiler would need to support source-maps and resolve references while compiling? That doesn't sound simple.

I would strongly prefer to leverage the JSX compiler built into my language - preserve does not sound like a good option.

[mhegazy]

There are other parts of the emitter than the name of the variable. for instance, in React, tag names starting with lower case, are treated as built in and always emitted as strings, where as uppercase ones are not. similarly, white spaces has its own rules in react emit. there is also serializing strings, etc.. I would expect frameworks to have differences, and I will find it misleading to say that we support other frameworks, where in fact we do not.

[mindplay-dk]

I would expect frameworks to have differences, and I will find it misleading to say that we support other frameworks, where in fact we do not.

I see. That's a shame. I thought the goal was to be a general-purpose programming language - now it sounds like Typescript is actually part framework and part language, or at the very least, it's now tailored for one particular framework.

I think that's a very odd decision - instead of building a feature that could be generally useful and enable people to do new and original things, possibly catering to a lot more people and a lot of new ideas, you chose one specific framework, which seems really opinionated.

Just my opinion of course, but frameworks generally have a substantially shorter life-span than languages. IMO, this is going to to shorten the shelf-life of Typescript tremendously. I really wish you had made something that everyone could enjoy, regardless of their taste in frameworks...

[danquirk]

If you peruse the various discussions in issues like #3203 you'll see that quite a bit of effort and thought went into making the JSX support as generalized as possible while also supporting the primary use case of today (React). There is very little coupling and as noted with --jsx preserve it's very possible to run a second tool over your output to get the emit you need for the framework of choice.

[benlesh]

If I had a request, it would be to please stick to what Babel has already done in this area.

For example a comment at the top of a file can be used to adjust output as well: /** @jsx h */ changes it to h('pre', {}, [])

[mindplay-dk]

I feel like I'm hearing conflicting stories here:

the typescript team would not want to take on the responsibility of emitting to multiple frameworks

Okay, but:

quite a bit of effort and thought went into making the JSX support as generalized as possible

So what are you saying, folks?

JSX support should be generalized, but you want to emit for only one framework?

I'm afraid I don't follow. There's nothing general about supporting one select framework - that is, by my definition, the opposite of general.

To clarify, I'm not asking you to support other frameworks - I'm asking you to make this feature configurable enough to allow the community to implement support for other frameworks. I'm suggesting that making the hard-coded React reference configurable is one way to do that. It doesn't make you responsible for integration with any other frameworks, I don't believe anybody would assume that - but it would permit others to do so, without feeling like they have to "hack" Typescript or "polyfill" React.

@danquirk I did follow these discussion, and I participated in another thread than the one you mentioned above. I didn't feel like like anyone was listening though, which was odd, a bit of a let-down, and btw the only time I've ever participated in these discussions and felt like I was being ignored. It was my impression that minds were already made up and perhaps React was too popular a force to go up against. I still feel that way. As someone at my office remarked today, Typescript is now actually a framework and not just a language, which is kind of sad...