Support JSX-Fragments with custom jsxFactory

[marvinhagemeister]

Really love the new JSX-Fragment syntax. It's great 💯

I was wondering if we could enable it for custom jsxFactory in the future. I'd really love to use this feature outside of react 👍

Use cases
Basically any non-react framework that works with jsx (mithril, preact, custom ones...).

Current workaround:

// my-library.ts
import { h, Fragment } from "./my-library";

export const React = {
  createElement: h,
  Fragment,
}

[RyanCavanaugh]

Ben Lichtman (@uniqueiniquity) can you investigate how other frameworks emit this to see what we should do to support this?

[dyst5422]

I have another use case of generating XML files where including extra tags is not an option.

I have no idea how this may be implemented, but the need is great enough for our team that I would be willing to spend some time on it.

[uniqueiniquity]

After a brief search, it seems that the only React alternative (out of Mithril, Preact, Virtual-DOM, and Deku) that implements fragments is Mithril, which uses m.fragment(attrs, children) instread of React's approach.

However, I think the key observation is here: preactjs/preact#946 (comment)
By providing a way to specify an alternative to React.Fragment like Babel does, we both open the possibility for frameworks to provide an implementation as well as for people today to use span or similar to patch the behavior. So it seems worth considering to me.

[mikelnrd]

Hi. Also implementing a framework needing a custom tsx implementation supporting JSX Fragments. I think this could be best solved with a compiler option to allow replacing React.Fragment with a user-defined string in the same way that React.createElement is currently replaced using the jsxFactory setting.

For the Mithral case: Mithral would just need to add a simple function that calls m.fragment(attr, children) if the element is a React.Fragment (whatever this is replaced with ie m.Fragment) and calls the usual m.createElement otherwise - with the user settingjsxFactory to be this simple wrapper function.

[dyst5422]

I think this still belongs to the domain of having the whole JSX type system refer to the factory method type and allow the factory method to deal with empty braces however the particular implementation desires.

[wnayes]

My 2 cents on how this could be implemented...

Proposal

Fragment shorthand syntax <> ... </> indicates a JSX element should be created with a special "Fragment" type. To offer custom JSX factories some flexibility, a new FragmentProperty interface could be added to the JSX namespace that defines what the name of the Fragment type is.

For example, React would define it this way:

declare namespace JSX {
    interface FragmentProperty { Fragment: {}; }
}

If a custom JSX factory does not implement this interface, using the shorthand syntax would be disallowed.

The Fragment type should not be constrained to the JSX.ElementClass, as it's just going to be some constant in most cases, not a class. This is a pain point in React's definitions, where it has to declare the Fragment type as being a ComponentType.

While I generally wish type checking was done through the createElement signature as issue 21699 seems to be covering, the definition of the special Fragment constant seems like a good use of the JSX namespace. The createElement signature can't really indicate which particular type constant is the one associated with the fragment shorthand syntax.