Implement React's jsx/jsxs Factory Changes

https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md

Major changes for us:

JSX children are always installed as an array on the props object - not as trailing arguments.
key will be passed separately from other props (in place of children)

Also of note:

defaultProps will be deprecated on function components
Spreading key will be deprecated
String refs will be deprecated

We might need new jsx flags, or jsxFactory flags, or something similar. Checking might need to be changed to reflect this as well depending on if/how we resolve createElement calls.

I currently use "jsx": "react", "jsxFactory": "h" which can be seen here:

https://github.com/opennetwork/vgraph.dev/blob/master/tsconfig.json#L25

h follows the style of the current createElement function, will there be an alternative that can be used in place?

https://github.com/reactjs/rfcs/blob/createlement-rfc/text/0000-create-element-changes.md

Cambios importantes para nosotros:

JSX childrensiempre se instala como una matriz en el objeto de utilería, no como argumentos finales.

keyse pasará por separado de otros accesorios (en lugar de children)

También de nota:

defaultProps será obsoleto en los componentes de la función

La difusión keyserá obsoleta

La cadena refsquedará en desuso

Es posible que necesitemos nuevas jsxbanderas, o jsxFactorybanderas, o algo similar. Comprobación necesidad fuerzas para ser cambiado para reflejar esto también dependiendo de si / cómo resolvemos createElementlas llamadas.

It's nearing the end of January 2020, coming up on 1 year from when reactjs/rfcs#107 was opened. It's still open for comments, a finalized set of changes still having not been accepted. I guess we'll keep monitoring it?

The first step has just been completed and shipped in Babel 7.9.0:

Blog post: https://babeljs.io/blog/2020/03/16/7.9.0#a-new-jsx-transform-11154-https-githubcom-babel-babel-pull-11154
PR: babel/babel#11154

This new transform eliminates the need for users having to add React in scope of their js files in order for jsx to work, as it is injected by the transform. There's some talk in the PR of why this isn't solved with pragmas:

Distinguishing between jsx/jsxs/jsxDEV/createElement is an implementation detail for React and will change in the future. Therefore, we don't think that it makes sense to add a pragma option for all of them. In addition, the signature for jsx/jsxs/etc. is different than createElement, so Preact/Inferno/etc. will not be able to use the new transform the way they currently are.

I'm not familiar with the internals of this PR, I'm just an enthused bystander but I think changes would be something like:

When the jsx compiler option is set to preserve or react-native, don't throw a warning if you use JSX but React is not in scope - as the import to the jsx factory function would be added by a further transform step (i.e. Babel)
Add a new value to the jsx compiler option jsx-automatic (name up for debate, but this is based on the option for the babel transform), that will transform code in a similar manner to babel-plugin-transform-react-jsx as discussed in Add experimental version of the babel-plugin-transform-react-jsx transform babel/babel#11154.

Will adding the import work here? TS Transformers are unable to successfully add imports during a transformation - unless internally it's done a little differently for jsx transformation (before the binding step)? Which is a shame tbh - would love for transformers to be first class! 😞

Change JSX transpilers to use a new element creation method.
 - Always pass children as props.
 - Pass key separately from other props.
 - In DEV,
   - Pass a flag determining if it was static or not.
   - Pass __source and __self separately from other props.

The goal is to bring element creation down to this logic:

function jsx(type, props, key) {
  return {
    $$typeof: ReactElementSymbol,
    type,
    key,
    props,
  };
}

How is one supposed to infer the meaning of Change JSX transpilers to use a new element creation method. and Always pass children as props. ?

I read it as asking for changes being make to the jsxFactory function api ?

Am I misreading this ?

Noj Vek (@nojvek)

Noj Vek (@nojvek) https://babeljs.io/blog/2020/03/16/7.9.0#a-new-jsx-transform-11154-https-githubcom-babel-babel-pull-11154
Maybe this will add more context to what's going on.

Nicolas Stepien (@nstepien)

Thanks Nicolas Stepien (@nstepien), that deffo provides more context.

IIUC (If I understand correctly) The ask from typescript is to have another compiler flag like jsxRuntime: automatic | classic like babel right ? i.e Take existing jsx but emit in a different manner depending on runtime flag?

I guess in a way this boils down to the eternal "bake it into core" vs "make it an extension" tradeoff.

There are other interesting projects going on around in the JSX space. e.g https://github.com/ryansolid/solid

Solid works with jsx but emits code like https://svelte.dev/. It does away with virtual dom overhead.

So in terms of Typescript direction, the question that begs answering is if Typescript does specific emits for new React jsxs and new compiler flags, would typescript also do emits for other frameworks that emit jsx in different ways. How much does Typescript give special preference to React over other frameworks?

Is this something that should be done via the transformer plugin api, so it's extensible enough but the core responsibility of Typescript remains at the parser + checker level.

Again, this is just food for thought.

I'm all for evolution of frontend tooling to be simpler, more performant and easier to use.

Nicolas Stepien (@nstepien)

Thanks Nicolas Stepien (@nstepien), that deffo provides more context.

IIUC (If I understand correctly) The ask from typescript is to have another compiler flag like jsxRuntime: automatic | classic like babel right ? i.e Take existing jsx but emit in a different manner depending on runtime flag?

I guess in a way this boils down to the eternal "bake it into core" vs "make it an extension" tradeoff.

There are other interesting projects going on around in the JSX space. e.g https://github.com/ryansolid/solid

Solid works with jsx but emits code like https://svelte.dev/. It does away with virtual dom overhead.

So in terms of Typescript direction, the question that begs answering is if Typescript does specific emits for new React jsxs and new compiler flags, would typescript also do emits for other frameworks that emit jsx in different ways. How much does Typescript give special preference to React over other frameworks?

Is this something that should be done via the transformer plugin api, so it's extensible enough but the core responsibility of Typescript remains at the parser + checker level.

Again, this is just food for thought.

I'm all for evolution of frontend tooling to be simpler, more performant and easier to use.

Noj Vek (@nojvek)

I think the wise move is definitely to make it as generic (and therefore, pluggable) as possible, though, I expect most frameworks that rely on JSX will over time migrate to the new jsx and jsxDev style functions, if history is any precedent here.

The real issue with leaving it up to being plugins, is that the Compiler API documentation just isn't great. It feels very neglected in comparison (I have this same gripe with babel, for what its worth). Also, with plugins you can only load them via the Node Compiler APIs, you can't have (IIRC) transform plugins added into the tsconfig under plugins (that appears to only be reserved for the editor plugins).

If the story around Plugins gets cleaned up (at least with much better and more detailed documentation, even if the API isn't completely stable), then relying on plugins is the way forward, and you could use React as a reference implementation of said plugins. I think that would be very acceptable.

Daniel Rosenwasser (@DanielRosenwasser)

If the story around Plugins gets cleaned up (at least with much better and more detailed documentation, even if the API isn't completely stable), then relying on plugins is the way forward, and you could use React as a reference implementation of said plugins. I think that would be very acceptable.

perhaps something to think about Daniel Rosenwasser (@DanielRosenwasser) re: making compiler plugins more friendly so Typescript doesn't have to bake everything in it's core.

I'd love to have tsconfig.json support plugins like https://github.com/cevek/ttypescript. There's #14419 which as a ton of 👍 upvotes and wouldn't be too hard to implement.

However some of the Typescript core members have mentioned it won't come anytime soon. I'm not sure exactly why. #14419 (comment)

In any case, don't want to derail the conversation on this topic. I'm not a core Typescript member, it's their call at the end of the day. All I care is that Typescript remains nimble and does a few things really really well like Typechecking and code completion, rather than try to do many things but in a subpar way. It's already a 50MB install.

Daniel Rosenwasser (@DanielRosenwasser)

Daniel Rosenwasser (@DanielRosenwasser) Will this release in TypeScript 4.0.1 ？I found this issue is in Milestone 4.0.1

Thanks, I've rescheduled to 4.1.

Specifically, we have a draft up (#39199), but the babel transform equivalent is still experimental, and the react changes to allow use of this emit haven't shipped in a stable react version yet; so we may wait until react 17 actually ships.

Noj Vek (@nojvek)

So in terms of Typescript direction, the question that begs answering is if Typescript does specific emits for new React jsxs and new compiler flags, would typescript also do emits for other frameworks that emit jsx in different ways. How much does Typescript give special preference to React over other frameworks?

Noj Vek (@nojvek) Yet another JSX-based framework author here. The new changes (jsx and jsxImportSource tsconfig options) have made things simpler actually. The emitted code seems generic and not tied to React. At least for me, it was quite easy to adopt.

Navigation Menu

Repository navigation

Implement React's `jsx`/`jsxs` Factory Changes #34547

25 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Implement React's jsx/jsxs Factory Changes #34547

Description

Activity

fabiancook commented on Oct 18, 2019

refhu commented on Dec 10, 2019

weswigham commented on Jan 21, 2020

BPScott commented on Mar 20, 2020

itsdouges commented on Mar 20, 2020

25 remaining items

nojvek commented on Jun 18, 2020

nstepien commented on Jun 18, 2020

nojvek commented on Jun 18, 2020

ScottAwesome commented on Jul 15, 2020

nojvek commented on Jul 15, 2020

xiaoxiangmoe commented on Jul 23, 2020

DanielRosenwasser commented on Jul 23, 2020

weswigham commented on Jul 23, 2020

jeswin commented on Dec 30, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Implement React's `jsx`/`jsxs` Factory Changes #34547