3 ms·
This is a missed opportunity to make JSX more than solely about UI and I'm pretty disappointed about it. JSX is really a way to describe a hierarchy of deferre
by phpnode 6y ago
This is a missed opportunity to make JSX more than solely about UI and I'm pretty disappointed about it.
JSX is really a way to describe a hierarchy of deferred function calls independent of their callers. This could be tremendously useful in a number of different contexts, not just UI. What would a state machine look like if the states could be described in JSX? What would rx.js look like if this mechanism was available?
The current tooling makes experimenting with possible alternate use cases pretty awkward, and so basically no one is doing work in this area.
I believe that these changes, particularly the `jsx` and `jsxs` auto import, will make it even harder to separate JSX as a concept from React and React-like libraries. It'll make it harder to standardise JSX, which is frustrating as it's the most supported ECMAScript syntax extension by a long way.
My modest proposal is that a JSX element desugars to a call to a block scoped identifier called `jsx`, so I can do something like this:
import { jsx } from 'react';
import { elementCreator } from 'somelib';
const someFunction = () => {
const { jsx } = elementCreator();
return <iAmNotAReactElement />;
};
const MyReactComponent = () => <div>cool</div>;
Taking this alternative approach would give developers a widely supported syntax extension that could allow for some really innovative solutions. The current path is going to do the opposite.
I understand that there are perf optimisations that React can do if they control all of this. But I feel like they're looking at this too narrowly, from only the perspective of UI. They have the power to open up a lot more opportunities.
- tomasreimers 6y agoOut of curiosity, why do you prefer JSX to nesting functions? I understand that for HTML you want to meet developers where they are, but that doesn't necessarily apply to other use cases...
- phpnode 6y agoJSX is a tree of deferred function calls. It's nothing to do with HTML, despite them looking similar. Normal function calls are not equivalent
- nesarkvechnep 6y agoWell, yeah. Can't you defer normal functions?
- phpnode 6y agoIt can be done if you write your code like this: function MyThing() { return ( el(A, {value: 123}, [ el(B, {value: 456, foo: true}, [ el(C, {awesome: true}), el(D, {awful: false}) ]) ]) ); } but there's a reason people prefer JSX syntax
- aylmao 6y agoTBH this sounds like it should be a new transform, not in the default one. Speaking for myself, I rather this be an alternative so I can get the best perf on my React apps, but have the option to switch to this when experimenting with using JSX for other things. This is an interesting concept, you should build it (:
- phpnode 6y agoWriting an alternative babel plugin to do the transform this way would be pretty trivial, but doing so for TypeScript is not (officially) possible. TS is going to choose one and it's going to be the one React uses. Also the decision to split React's createElement() into jsx() and jsxs() means that to maintain compatibility all libs would have to do the same, and provide both functions, all because of an implementation quirk in React. JSX should be a standalone thing. It's not intrinsically React, and shouldn't bend to React's needs alone.