You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. I've searched through the various issues (as well as other places this has been discussed) and I don't see a current open issue to address the lack of custom JSX pragma support.
As discussed elsewhere, other transpilers allow specifying any function name to insert when producing hyperscript from JSX. It's worth noting that hyperscript predates React, and is a format shared by a large number of libraries entirely separate from the React project. Currently, TypeScript only allows configuration of an Object on which to invoke .createElement(), however the original implementations and many descendants thereof simply use h(). You can read my attempt to document some of the context and background here.
The configuration would presumably look something like this:
Your requirement can be implements via " custom syntax tree transformations " . So I don't think it's necessary for us to increase tsconfig 's complexity.
And I think that's a great idea, however the tsconfig already has an option for JSX (that only supports React.) I don't see why we'd support just the first half of the function call.
WanderWang (@WanderWang) this is very much a userland feature. Most users of TypeScript would not be compelled to extend TypeScript itself simply to account for a common use-case.
My suggestion could replace the existing "jsxNamespace" config property, since jsxPragma enables a superset of use-cases, while still allowing the default to remain "React.createElement".
Currently, TypeScript forces users to build shims for non-React JSX use-cases, which is significantly more cumbersome than needing to know about another (or a different) configuration property.
Basarat Ali Syed (@basarat) yes, this is what people currently do. However, this is a second-class experience and difficult to explain in documentation.
Reacted by Seth Livingston, Martin Hochel and jominions
Reacted by Basarat Ali Syed, K, Martin Hochel and Santiago Lezica
My use-case is to support JSX within skate.js. skatejs has a hyperscript compliant API import { h } from 'skatejs';, so all that's missing is JSX pragma support or something equivalent.
If this flag is specified, JSX elements in react emit mode no longer require the React identifier to be present.
In the case of // @jsxFactory: a, we should require the a identifier to be present right? Following on that // @jsxFactory: a.b would still require just a to be present.
I think we should require React to be present if jsxFactory: React.createElement is used.
I also need to look into how React.__spread should be dealt with. I hadn't realised that reactNamespace was also used to describe which object .__spread hangs off. nevermind .__spread is no longer used.
Activity
WanderWang commentedon Jul 9, 2016
I have a different view
consider this proposal
Proposal: Replace emitter with syntax tree transformations and a simplified node emitter.
Your requirement can be implements via " custom syntax tree transformations " . So I don't think it's necessary for us to increase tsconfig 's complexity.
PaulBGD commentedon Jul 9, 2016
And I think that's a great idea, however the tsconfig already has an option for JSX (that only supports React.) I don't see why we'd support just the first half of the function call.
developit commentedon Jul 9, 2016
WanderWang (@WanderWang) this is very much a userland feature. Most users of TypeScript would not be compelled to extend TypeScript itself simply to account for a common use-case.
My suggestion could replace the existing
"jsxNamespace"config property, sincejsxPragmaenables a superset of use-cases, while still allowing the default to remain"React.createElement".Currently, TypeScript forces users to build shims for non-React JSX use-cases, which is significantly more cumbersome than needing to know about another (or a different) configuration property.
basarat commentedon Jul 9, 2016
workaround:
developit commentedon Jul 10, 2016
Basarat Ali Syed (@basarat) yes, this is what people currently do. However, this is a second-class experience and difficult to explain in documentation.
bradleyayers commentedon Sep 23, 2016
My use-case is to support JSX within skate.js. skatejs has a hyperscript compliant API
import { h } from 'skatejs';, so all that's missing is JSX pragma support or something equivalent.RyanCavanaugh commentedon Sep 28, 2016
Accepting PRs for a flag
jsxFactorywhich accepts a string, like"h"or"React.createElement"reactemit mode no longer require theReactidentifier to be present3 remaining items
bradleyayers commentedon Sep 29, 2016
I'll raise a PR.
bradleyayers commentedon Sep 29, 2016
In the case of
// @jsxFactory: a, we should require theaidentifier to be present right? Following on that// @jsxFactory: a.bwould still require justato be present.I think we should require
Reactto be present ifjsxFactory: React.createElementis used.I also need to look into hownevermindReact.__spreadshould be dealt with. I hadn't realised thatreactNamespacewas also used to describe which object.__spreadhangs off..__spreadis no longer used.mhegazy commentedon Sep 29, 2016
sounds reasonable.
bradleyayers commentedon Sep 29, 2016
I've raised the PR — #11267.
tusharmath commentedon Nov 12, 2016
For future readers —
{ "compilerOptions": { "jsx": "react", "jsxFactory": "h" } }The above configuration will get you going.
mhegazy commentedon Nov 12, 2016
Edit: updated the jsxFactory property name in comment above.
tusharmath commentedon Nov 13, 2016
Mohamed Hegazy (@mhegazy) I get this error —
Unknown compiler option 'jsxFactory'mhegazy commentedon Nov 13, 2016
Use
typescript@next.nojvek commentedon Nov 14, 2016
This is awesome. Kudos for baking this as a compiler param.
streamich commentedon Oct 7, 2017
should compile to:
and them React could do: