
What should go into JSX 2.0? - bpierre
https://github.com/facebook/jsx/issues/65
======
jameslk
Nothing. Seriously, JSX works really well as it is. These proposals seem like
small enhancements, some of them for the wrong reasons.

> Computed attribute names.

If you need this, you're probably being too clever. If there's a legitimate
use for this, I've never seen it in the past 2 years I've been using JSX with
React.

> Object short hand notation.

> Drop the need for curlies around attribute values if they're a single
> literal, or parenthesis.

Is it really that much more work?

> Implicit do expressions.

> Conditionals

> Loops

If you need control statements in your JSX, you're doing it wrong. When you
need these things, this is a sign you need to break your code into smaller
chunks. Move this logic into separate functions, lambdas or variables and
interpolate them in. Now you've labeled your code and made it more composable.
This is called self-documenting code and it's a lot easier for others and your
future self to read.

All of these wouldn't be so bad if it wasn't a proposal to justify breaking
changes. I really don't want to have to deal with two versions of JSX that are
incompatible. That just sounds like hell.

~~~
arstin
I personally agree with this in the big scheme of things. Computed attribute
names seem overkill and I worry about adding logic to JSX. But, honestly, I
could care less if they were added if such features get other people all fired
up.

My personal taste though often does wish for object shorthand and dropping
curlies. My sense off the top of my head is that the majority of my actual
props look something like `<Widget user={user} id={id} timestamp={timestamp}
/>` since I mostly avoid setting up data inside JSX. Is it a big deal? Of
course not. But it would be nicer to just write `<Widget user id timestamp />`
or `<Widget $user $id $timestamp />` or whatever syntactic sorcery would be
settled on.

A modest advantage of dropping curlies is it reduces the already tiny force of
one argument for styling in CSS over JS: "prettier and less typing". I
certainly don't think they should be dropped just for this reason of course,
but could be a side effect worth noting.

~~~
joesb
You can do `<Widget {...{user, id, timestamp}} />`

~~~
arstin
Oh man you're right aren't you! I just might start doing that!

------
substack
Also keep in mind that javascript engines have a built-in mechanism for
including multi-line strings with a powerful substitution engine: tagged
template strings ([https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Template_literals)). The upside of template
strings is that you can run your code directly in node or electron without
using extra tooling first. It is possible and not hard to use tagged templates
with react, although few people do. It's more common in some other frontend
ecosystems.

~~~
pitaj
JSX isn't templating. It's representing a virtual dom tree of function calls
with a syntax more representative of the resulting markup.

~~~
substack
You can build virtual dom trees or use real dom nodes using something like
[https://www.npmjs.com/package/morphdom](https://www.npmjs.com/package/morphdom)
. Tagged template strings let you build these features in without custom
language extensions. See also:

* [https://www.npmjs.com/package/hyperx](https://www.npmjs.com/package/hyperx) * [https://www.npmjs.com/package/yo-yo](https://www.npmjs.com/package/yo-yo)

~~~
pitaj
Right, but these just do what JSX does, but in runtime instead of at compile
time.

------
maaaats
I like how the _if_ proposal is down voted, probably because it's mentioning
Angular. Conditional rendering in React is not always very clean. Most
codebases end up resorting with something similar to this in a container to
show a spinner while data is loading and rendering it when done.

<ConditionalSpinner renderIf={data}><PersonRenderer person={data.person}
/></ConditionalSpinner>

Problem is that the inner component will still be parsed and fail with cannot
read property person of undefined. Yes, you can do this with a simple
condition in your render function, but then it's not declarative any more.

~~~
msoad
It's the extreme fanboyism there! Wrapping every component that has ` _if`
attribute with an `if` statement should not result into that:

    
    
        <div *if={cond1 && cond2}>
            <div>foo</div>
        </div>
    
        // results to
        if (cond1 && cond2) {
            return React.createElement('div', null, 
                React.createElement('div', null, 'foo')
            );
        }
    

I'm not sure why this is bad? Because it's looking like Angular?!!

~~~
coderzach
It's bad because it's inconsistent with how every other attribute in jsx
works. Nothing else in jsx changes the control flow of the code.

~~~
msoad
It is 2.0 so it can have breaking changes

~~~
exogen
The parent didn't mention anything about backwards compatibility. They're
saying 2.0 with such a change would be inconsistent _with itself_. And they're
right.

------
peterkelly
What's wrong with just using the JavaScript/TypeScript syntax you already
have? It's trivial to write a few functions to create HTML elements and append
children. For example:

    
    
        import { h1, div, span, text } from 'html';
    
        const user = { name: 'Dave', age: '30' };
    
        return div('container',
            h1(text('User info')),
            div(span('field',text('Name')),text(user.name)),
            div(span('field',text('Age')),text(user.age)),
        );
    

I don't understand why there's so much activity in creating new
languages/language extensions that duplicate functionality that can already be
expressed as is, with just a bit of basic library support.

CSS preprocessors are another example. Want to add loops, conditionals, and
user defined functions to your CSS superset? Why not just use JS/TS instead,
which has all the control features and can output CSS text just as well as
Less/Sass/SCSS/flavour of the month.

~~~
Zezima
You just wrote elm code in javascript

~~~
abritinthebay
That style was old before Elm. Elm does it rather well tho

------
arnold_palmur
I definitely think fragments should be an added feature of a 2.0 version of
JSX - just take a look at this Github issue that continues to house active
discussion now for 2+ years.

[https://github.com/facebook/react/issues/2127](https://github.com/facebook/react/issues/2127)

~~~
spicyj
Yes, this is often-requested. We don't necessarily need to change JSX to add
this to React though. With our current implementation it's a pain to support
it but we're working on it.

------
hex13
I wish it could be possible to write this:

const animal = "cat"; <Component {animal} /> equivalent to: <Component
animal={animal} />

~~~
skosch
How about <Component {{animal}} /> ? Because that should already work, no?

~~~
alistairjcbrown
You'd have to spread in the object, right?

<Component {...{animal}} />

~~~
hex13
I know, but it's too verbose for me. BTW there is a discussion about this:
[https://github.com/facebook/jsx/issues/23](https://github.com/facebook/jsx/issues/23)

------
cratermoon
What could be safely removed from JSX?

------
inimino
My only real gripe about JSX is the crazy attribute casing rules. If it looks
like HTML then attributes should be case-insensitive just like HTML. The worst
of it is (unless this has changed) they are just silently dropped without any
error message.

~~~
insin
The React ESLint plugin's no-unknown-property rule is handy for catching (and
automatically fixing) this:

[https://github.com/yannickcr/eslint-plugin-
react/blob/master...](https://github.com/yannickcr/eslint-plugin-
react/blob/master/docs/rules/no-unknown-property.md)

~~~
inimino
Good to know, thanks.

That's a good stop-gap, but the tool itself should either pass through
everything to the HTML or throw errors on anything that isn't going to get
passed through. The silent failure mode is a UX bug.

~~~
ramchip
If I understand your comment correctly, this is checked in more recent
versions of React: [https://facebook.github.io/react/warnings/unknown-
prop.html](https://facebook.github.io/react/warnings/unknown-prop.html)

~~~
inimino
It does seem to be the same issue. That's great, it will certainly avoid some
frustration.

------
Waterluvian
Conditional rendering is all I really hurt for. But I would prefer not having
a 2.0 at all if it wasn't fully backwards compatible.

------
kevinSuttle
[http://kevinsuttle.com/posts/jsx-2-adobe-
flex](http://kevinsuttle.com/posts/jsx-2-adobe-flex)

------
Marazan
I'd like a good system for conditional child components. I liked Flex's
system.

------
Trufa
Regardless of the changes, I really think that this is very well managed
community wise, not strictly comparable, but hopefully stuff like this will
avoid fragmentation of the community like angular 1/2, python 2/3.

------
venomsnake
Decent way to comment ...

~~~
jazoom
This is all I want

------
donpark
Just one thing: ability to return array of elements as result.

------
akhatri_aus
Some kind of way to parse variables only if they exist. The equivalent of (in
Coffeescript)

a = {b:'c'}

a?.c //undefined

a.b //'c'

b?.c //undefined

~~~
peddicord
Correct me if I'm wrong, but that doesn't seem like the domain of JSX. That's
just JavaScript.

------
mercurial
Since when does Reason have JSX?

~~~
vcarl
JSX is actually a generic transformation of XML like structures to function
calls. Since it's mostly used with React, that's the default, but you can use
any function you like. It's the "pragma" option in the config for the plugin.

[https://babeljs.io/docs/plugins/transform-react-
jsx/](https://babeljs.io/docs/plugins/transform-react-jsx/)

------
fbreduc
make it s-exp?

~~~
ng12
You mean Elm?

------
JBiserkov
"What should go into JSX 2.0?" would be a much clearer title outside of the
context of the GitHub issue.

~~~
blablabla123
Yup, even the issues not marked controversial seem so to me. I think JSX is
quite nice but it has its limits/annoyances. One is obviously that it's not
real HTML5.

I would like to see a successor that is more like HTML5 without the X. No idea
how that could be realized though... ;)

~~~
rattray
Sorry, what do you mean by this? (For those unfamiliar with the deviations)

~~~
djur
I started using React/JSX professionally in the last few months, so some of
these are fresh in my head. Differences I'm aware of:

1) JSX creates virtual DOM objects, not HTML tags. In places where the DOM and
HTML use different names for the same thing, JSX uses the DOM's name. In
particular, the "class" attribute is called "className" and the "style"
attribute takes an object like { color: "white" } instead of a string like
"color: white" (and the keys are like "backgroundImage" rather than
"background-image"). The latter rarely comes up, but the former bites me all
the time when incorporating markup from designers.

2) JSX requires all tags to be closed, like XHTML and all XML dialects. HTML 5
declares some tags to be self-closing, like IMG.

3) JSX removes whitespace padding inside elements. This usually results in the
same visual result, except for those cases where HTML actually cares about
extra whitespace (like in PRE and TEXTAREA).

4) Regarding TEXTAREA, you're encouraged not to use the inner content of the
tag to define its default value. Instead, you treat it like an INPUT. (I think
this is if anything an improvement.)

5) INPUT tags have some special behavior related to default values, but that's
really more about React than JSX per se.

Overall I have found JSX pretty easy to get into. I appreciate that it really
is just a very thin layer over underlying JS. I'm not totally sold on this
approach versus the many, many, many other HTML templating systems out there,
but at least it's easy to understand.

~~~
blablabla123
Regarding 1)... like 5) that's React, so you could write a JSX transpiler that
creates actual DOM objects.

------
rsrsrs86
Absolute inelegant shit, use Elm

