React, JSX and ES6: The Weird Parts | Hacker News Reader

React, JSX and ES6: The Weird Parts

ponyfoo.com

23 pointsponyfoo21 comments

>> <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.

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.

I've worked with a system that was similar to the virtual dom, and I can tell that the ponyfoo author has NOT tried to work with text nodes. Browsers will merge those in an instant. (Side Note: IE in general, including IE11, has had some WEIRD text node behavior, that changes between versions of IE)

So making each updatable component an actual (non-text) DOM Node is an unfortunate requirement.

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=...>.

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.

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> );

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.

I use these a bit and think they're great! If your logic is more complicated than one line it doesn't belong in there.

Fully agree. To call lack of conditionals a "limitation of JSX" is also very misleading. JSX is a pretty simple wrapper for Javascript function calls. The fact that you can't put an if statement in your JSX is due to the fact that you can't supply an if statement as an argument to a Javascript function.

I consider it a big positive that you can't.

If you really need to, I don't mind this pattern...

{conditional && (

  <div>throw whatever you want</div>
  <div>in here.</span>

)}

Of course, this doesn't actually work, because you have two root elements in that expression. You have to wrap them in an enclosing tag or inject them another way.

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.

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.

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

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

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. :(

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.

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.

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.

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.

One of the major selling points of React is isomorphic templating though, so it's a valid criticism.

Reply on news.ycombinator.com