

React, JSX and ES6: The Weird Parts - ponyfoo
http://ponyfoo.com/articles/react-jsx-and-es6-the-weird-parts

======
vogre
>> <span>foo {'bar'} {'baz'}</span>

well, you just should get the idea that these curly braces are not for
interpolation. It's just convenient way to define a component tree. If you
want interpolation, you should use <span>{`foo ${'bar'} ${'baz'}`}</span>
syntax.

~~~
k__
I dodged this bullet, because the first time I needed a string with two
dynamic parts, was in an attribute.

This doesn't work:

    
    
        <h1 className='{a} {b}'>...</h1>
    

So I did this:

    
    
        <h1 className={`${a} ${b}`}>...</h1>
    

And then simply used this style everywhere, because it worked for text-nodes
and attributes.

------
dgreensp
The criticisms about unexpected DOM elements and ugly conditionals are spot-
on. Also, bringing back the confusing differences between XML and HTML (pop
quiz: What does <div/><div/> do? It's different in JSX and HTML), and
introducing various other random incompatibilities, like having to write <div
className=...> and <textarea value=...>.

------
meesles
I disagree with this point: _Using conditionals in your view components_.

Putting if statements into your view is not the React way. You should be
rendering something like {productList}, and that productList() function should
be the one handling any outstanding logic. Even better, Your React should be
generic enough to accept data you filter and edit in your controllers.

~~~
funkiee
More on that point. The reason you cannot use if/else within JSX is because
the statement needs to evaluate to an expression. If you really need to use
if/else logic embedded, a ternary operator would work just fine.

return ( <nav> <Home /> { loggedIn ? <LogoutButton /> : <LoginButton /> }
</nav> );

~~~
muzmath
I was hoping someone would mention this. Between this and an extended rant
about `dangerouslySetHtml`, I would say this author was really scraping hard
to find negative things about React. Poor quality article.

------
kentor
I love JSX because all it is one big javascript expression. I disagree with
the statement

    
    
       For some reason, React’s JSX make this unnecessarily complicated by not being able to use if statements inside code blocks.
    

Using if inside an expression isn't javascript! It would be some shitty
templating language, and I'm grateful it didn't turn out that way.

~~~
k__
Yes. Seems more of a JavaScript than a JSX problem for me.

I'd love to have a JSX like syntax in LiveScript, because it has if-
expressions.

~~~
mikewhy
> Seems more of a JavaScript than a JSX problem for me

Well put, since the issue doesn't appear when using CoffeeScript.

------
ergothus
Funny that the author didn't list JSX/React's form behavior as "weird".

Basically, on every keypress you need to capture the change and rerender. It
may be fast, it may be what the browser is doing under the hood, but it feels
VERY weird.

It also means that things like divs with contenteditable on them are basically
unworkable in the current version. :(

~~~
kentor
Yeah.. I ran into perf problems with that in IE9 in a VM. But that may be the
price to pay for a single source of truth.

------
catpolice
Yeah the author seems to be thinking about the DOM from the server side, where
the end point of all rendering calls is a string that gets sent to the client.
This misses out on baaasically everything that sets React apart from all the
template-based frameworks out there.

~~~
calvin
For faster initial render and SEO purposes it's important for many sites to
render their content on the server first. React may not be targeted primarily
at this type of application, but it's a legitimate use case for the author to
consider and address.

~~~
catpolice
Absolutely, but at the same time, sacrificing client side rendering
performance isn't the answer, and some of his suggestions about how he wishes
React worked would involve doing just that. The author's complaint isn't that
server-side rendering is harmfully impacted, it's that JSX has some
expressively awkward bits. But it has some of those awkward bits because it
more or less has to if React is going to work as well as it does on the client
side. JSX was designed the way that it was to enable client-side
functionality, and the author doesn't seem to acknowledge that, so it seems
like he's criticizing without fully understanding.

