I'd suggest avoiding that, since the inner JX expression will be evaluated even if cond is false. In the best case this just means some unnecessary allocations, but in other cases it can cause unexpected errors (e.g. you check obj != null then try to use it inside the if).
Well, actually. it don't have to be. Just React decides to compile JSX in that way.
Vue 3 also supports JSX. But it keep the content of children lazily evaluated.
Their compiler compile a JSX `<Parent><Child /></Parent>` to structure like `h(Parent, {}, { default: () => h(Child, {}, {}) })` . So the child jsx tag is never evaluated unless the Parent component want to.
It's really not a syntax limitation because JSX never specify that the children of element must be eagerly evaluated.
That seems like a dangerous reinterpretation of JSX. It's just a literal syntax, it's not meant to be lazily evaluated.
Having a JSX compiler interpret <Parent><Child /></Parent> as h(Parent, {}, { default: () => h(Child, {}, {}) }) would be like having a JS compiler interpret
let parent = {
child: {}
};
let parent = {};
Object.defineProperty(parent, 'child', { get: () => ({}) })
h(Parent, {}, [ h(Child, {}, []) ])
In practice, every framework interpret jsx in slightly different way. React has own. Vue has own. Solid has own. And even react itself interpret JSX in 2 way (the new and old jsx compiler). So I feel there really isn't a rule that you can't compile jsx in some specific way because the output is never part of the specification of jsx from the beginning.
<If cond={...} then={() =>
...
} els={() =>
...
} />
{ some_condition ? (
<H2>It was true</H2>
<H2>It was false</H2>
)