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.
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.
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.
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.
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.
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'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=...>.
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. :(
21 comments
[ 2.6 ms ] story [ 37.3 ms ] threadPutting 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.
return ( <nav> <Home /> { loggedIn ? <LogoutButton /> : <LoginButton /> } </nav> );
{conditional && (
)}I'd love to have a JSX like syntax in LiveScript, because it has if-expressions.
Well put, since the issue doesn't appear when using CoffeeScript.
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.
This doesn't work:
So I did this: And then simply used this style everywhere, because it worked for text-nodes and attributes.So making each updatable component an actual (non-text) DOM Node is an unfortunate requirement.
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. :(