Separate JSX/TSX from React and present it as a general XML-in-JS solution
Opened this issue · 8 comments
🔍 Search Terms
"jsx react", "jsx scope", "jsx generic"
✅ Viability Checklist
- This wouldn't be a breaking change in existing TypeScript/JavaScript code
- This wouldn't change the runtime behavior of existing JavaScript code
- This could be implemented without emitting different JS based on the types of the expressions
- This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals
⭐ Suggestion
Right now TypeScript's JSX/TSX options are tied to React:
- This includes
jsxtsconfig option names (react,react-jsx,react-nativeand etc.) - And TypeScript docs (official docs describe JSX/TSX usage only giving examples for React).
All this creates great confusion and makes new people think that JSX/TSX stuff is ONLY used for React which damages the whole idea of jsx. Yes, it used to be like that from historical point of view, but I think it is time to separate one from another.
The problem is that current option names (and tsconfig docs) are not self-explanatory for someone who never worked with React or front end in general.
I think that jsx has grown enought to have it's own independent standart.
Something like this:
"jsx": {
"mode": "scope" | "import" | "preserve",
"elementTypeStrictness": "strict" | "relaxed",
"elementSpec": "two-argument" | "three-argument",
"elementFactory": "jsx",
"fragmentFactory": "Fragment",
"importSource": "...",
}From that perspective, React will be just one example of how this general feature can be used, not the only one!
Of course it also worth mentioning that there is a awaited by many feature request to provide full generic support for jsx nodes instead of widening to JSX.Element:
📃 Motivating Example
Separating JSX/TSX from React especially on docs level would attract more people to writing their own XML-in-JS languages, instead of using external tools.
💻 Use Cases
This is mainly useful for writing content with strict typings and full JS/TS environment support (variables, conditions, functions, comments and etc) — no need to use external Markdown/XML/... parsers.
Consider the following prose example:
export const pythagoreanTheorem = (
<Term
title="Pythagorean Theorem"
direction="row"
$snippet={{
search: { synonyms: ['Pythagoras', 'Right Triangle Theorem'] },
description:
'Fundamental theorem relating sides of a right triangle',
}}
>
<TermMain>
<p>
In any right triangle, the square of the length of the
hypotenuse <M>c</M> is equal to the sum of the squares of
the lengths of the other two sides <M>a</M> and <M>b</M>.
</p>
<BlockMath>{`
a^2 + b^2 = c^2
`}</BlockMath>
</TermMain>
<TermSection title="Geometric Interpretation">
<p>
The theorem can be visualized as the area of the square
constructed on the hypotenuse being equal to the sum of the
areas of the squares constructed on the other two sides.
This relationship holds true for all right triangles,
regardless of their size or orientation.
</p>
</TermSection>
<TermSection title="Common Examples">
<p>
The most well-known Pythagorean triple is <M>(3, 4, 5)</M>,
where <M>3^2 + 4^2 = 9 + 16 = 25 = 5^2</M>. Other common
triples include <M>(5, 12, 13)</M> and <M>(8, 15, 17)</M>.
</p>
</TermSection>
</Term>
);This is not a React code. All these tags are custom functions so we can parse it, detect writing errors on both compile and runtime levels, extract search snippets and do so much stuff! And all this within TypeScript — no external tools needed.
Of course XML-in-JS can be used not only for prose content, but for other structured data, that is easier to express with XML structures other than JS code.
Not to mention how flexible it is — we can save such XML structures to variables, export and import them in different files!
Your use-case is already supported by configuring the compiler accordingly, it hasn't been tied to React in a long time. And presenting it as "XML-in-JS" would be extremely misleading, as this is not XML.
@MartinJohns It does not have to be XML-in-JS but it sure looks like one and can be used like this, having in mind differences ofcourse.
I understand it can be used like this already by configuring the compiler.
My point is that configuring it is confusing as hell (confusing names and tag-function call structure) and looks more like you are configuring React, not your custom DSL.
It is double-confusing for me because I use Vue and never used React. So for a long time I though that all this .jsx/.tsx stuff was only intented for React.
My point is that configuring it is confusing as hell (confusing names and tag-function call structure) and looks more like you are configuring React, not your custom DSL.
It's to configure JSX, not "your custom DSL". It's JSX, not a customizable DSL solution (which would be way out of scope).
And it's documented in a few places:
I'm not sure what you're actually trying to suggest as an improvement. As it is, it's not tied to React at all, but it is still JSX. Either use jsx: preseve to keep the JSX as it is (and have other tooling handle it), or configure jsxFactory to use a custom-method and jsxImportSource for the relevant import.
The handbook section of docs is written in framework agnostic style and was very useful to me, I agree.
I'm not sure what you're actually trying to suggest as an improvement.
I suggest renaming (or adding new) jsx option names to framework agnostic ones: scope instead of react (because it just requires jsx and Fragment functions to be in scope of file that uses jsx and import instead of react-js (because it autoimports these two functions).
I appreciate that you put some time into this idea, but given that there is no real demand for this, I highly doubt that typescript is going to invest any time in developing this or maintaining the change if it were made for them. Obviously I don't speak for the typescript team, but just trying to temper some expectations early.
Maybe you could think like this: despite being utilized by other libraries, type: react and others are still owned by React.
It's React Team who put their resources into research and development of the transform from JSX to plain JavaScript.
Also it's React Team who worked together with compiler authors to popularize the transform, for example:
We also worked with the React team to provide a new JSX transform...
In the first place, JSX itself is specced by Meta for now, while it's just a wild spec and has't undergone the standardization process.
You see it is not like I am some kind of React hater who just wants everything about React to be removed from TypeScript because "I am Vue enjoyer", ofcourse not. The problem is that current option names (and tsconfig docs) are not self-explanatory for someone who never worked with React or front end in general.
I just think that jsx has grown enought to have it's own independent standart.
Something like this:
"jsx": {
"mode": "scope" | "import" | "preserve",
"elementTypings": "strict" | "relaxed",
"elementSpec": "two-argument" | "three-argument",
"elementFactory": "jsx",
"fragmentFactory": "Fragment",
"importSource": "...",
}I am also kind of hyped about it because I have never seen such XML-like structures support in other languages.
@RyanCavanaugh I updated the first message to make it more clear of what the suggestion is.
I've dabbled in alternate JSX usages occasionally. Improvements improvements in type checking JSX would be the most beneficial to me. It's far simpler for me to write my own babel plugin for a custom transform, than it is to typecheck the transform. If the transform is reasonably "react-like" in semantics, then the built-in type checking works well enough (assuming I provide my own JSX types), but even then #14279 would be a nice improvement. But that already has its own issue.
Changing the option names in tsconfig.json seems counterproductive, since it would be either a massive breaking change for existing projects, or would require keeping the old options around as aliases, adding to the confusion.
Less React-centric emphasis in the documentation would be nice, but not a huge gain, as developers creating their own JSX transforms should be knowledgable enough to read between lines there.