This allows one to sprinkle implicit returns throughout the entire body of one's function and I'm not sure what to think of that.
Also the syntactic rules around control flow within elements/literals/identifiers seem a bit inconsistent. Some things require curly braces, others don't.
By the way you can probably implement this to 90% without needing a compilation step for React. Just track what elements get created by react factory functions during the function component execution (similar to how hooks work), and treat any that weren't passed as children to another as implicit returns. This only breaks when they're used verbatim in expressions, but this library doesn't allow doing that without a special wrapper tag either. A library approach should probably add a lint rule to disallow it.
The only thing you can't implement as a library is some of the syntactic sugar that allows one to directly put control flow within elements without wrapping the thing in an IIFE.
Overall a bit too much magic for my taste. The style stuff is nice, but I'd prefer a library approach for that in a react app as well.
Finally here's something with rather strange output:
export component Test() {
<div>{Date.now()}</div>
if (Math.random() > 0.5) {
return;
}
<style> div { color: 'red' } </style>
}
So you either get the date when the component was most recently rendered, or the date when the page was loaded with a 50% chance each (should probably pick one). And the CSS is unconditional, which is not very intuitive.
I'm not sure how much of that is intended, and how much is a bug.
I think this is a step in wrong direction. We really need to move away from this XML inside/alongside JS ugliness prevalent in the webdev ecosystem.
What I really want are kotlin style builders or F# style computation expressions.
What is the point of stating your opinion if you're not going to explain why you believe that?
how are kotlin style builders or F# style computation expressions better than jsx, svelt, tsrx or any of the other sort-of-html in js/ts syntaxes?
I'm in love with everything about this.
An oxfmt plugin would be appreciated!
This allows one to sprinkle implicit returns throughout the entire body of one's function and I'm not sure what to think of that.
Also the syntactic rules around control flow within elements/literals/identifiers seem a bit inconsistent. Some things require curly braces, others don't.
By the way you can probably implement this to 90% without needing a compilation step for React. Just track what elements get created by react factory functions during the function component execution (similar to how hooks work), and treat any that weren't passed as children to another as implicit returns. This only breaks when they're used verbatim in expressions, but this library doesn't allow doing that without a special wrapper tag either. A library approach should probably add a lint rule to disallow it.
The only thing you can't implement as a library is some of the syntactic sugar that allows one to directly put control flow within elements without wrapping the thing in an IIFE.
Overall a bit too much magic for my taste. The style stuff is nice, but I'd prefer a library approach for that in a react app as well.
Finally here's something with rather strange output:
Yielding: So you either get the date when the component was most recently rendered, or the date when the page was loaded with a 50% chance each (should probably pick one). And the CSS is unconditional, which is not very intuitive.I'm not sure how much of that is intended, and how much is a bug.
There is definitely a bug there, I'll put up a fix in a bit. Thanks! :)