Repository: TypeScript
Issue: Allow JSX element tags to be symbols
Labels: Suggestion,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

es6 symbols JSX createElement element tag type intrinsic host

## Suggestion

Allow JSX element tags to be ES6 symbols instead of just strings, functions or classes.

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

JSX-based libraries like React have adopted the convention of using special upper-cased symbols as the tag of the JSX expression (`<Fragment />`, `<Suspense />`) as a way to provide intrinsic elements which aren’t callable and whose behavior are defined by the library rather than the tag.

Currently, TypeScript only allows JSX tags to be strings, functions or classes as defined by the JSX interface, and will throw errors like the following if Symbols are used:

```
error TS2604: JSX element type 'Fragment' does not have any construct or call signatures.
```

Libraries are therefore forced to lie about the actual typings of Symbol tags as something other than a `unique symbol`. For instance, React defines Symbol tags as `ExoticComponent` and pretends that the symbols are callable (https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L358-L364). The framework I work on (Crank.js) just defines symbols meant to be used as tags as `any` but this then has further repercussions when I attempt to, for instance, use these symbol types in interfaces.

Symbols are useful because they:
1. Allow intrinsic elements to be upper-cased. This allows people to provide renderer-provided element APIs which mirror XML languages which are case-sensitive.
2. Not globally scoped, so there is no possibility of namespace clashes, and can be imported/exported.
3. Can still work with the global `IntrinsicElements` interfaces to be strongly typed.

## Examples

```tsx
const Fragment = Symbol.for("crank.Fragment");
type Fragment = typeof Fragment;

const Portal = Symbol.for("crank.Portal");
type Portal = typeof Portal;

// should not error
const el = (
  <Fragment>{children}</Fragment>
);

declare namespace JSX {
    interface IntrinsicElements {
        foo: any;
        [Portal]: {root: any};
    }
}
```

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).