JSX Looks Like An Abomination

But it’s Good for You

Eric Elliott
May 20, 2015 · 7 min read

TL;DR

What is JSX?

JSX expressions evaluate to ReactElements. Think of them as shorthand for calling `React.createElement()`.

Babel has built-in support for JSX. If you need help getting that set up, read “How to Use ES6 for Isomorphic JavaScript Apps.”

Here’s a sample JSX expression for an editable email field:

Let’s break this down:

JavaScript Expressions

Styles

Events

Inline JSX

… and that’s where many developers tune out. At first glance, this looks like the unholy love child of 1990's DHTML and 2015 ES6. We’re talking some Frankenstein madness… right?

Well, not quite. Let’s take a closer look.

JSX is Not an HTML Template Language

It’s actually a declarative syntax that’s used to express the virtual DOM. JSX gets interpreted and converted to virtual DOM, which gets diffed against the real DOM. Rather than rewrite the whole DOM tree, only the differences get applied. That makes React renders fast.

Additionally, JSX builds in common protections against XSS attacks.

JSX is not limited to HTML. You can use it to create arbitrary object trees. Netflix uses that capability to mirror their web app architecture on a wide variety of devices using their own custom object model for TV rendering.

React Native uses it to render device-native UI elements.

In this sense, JSX is actually a lot more flexible and versatile than a Handlebars template can be.

JSX Event Handlers are NOT Like HTML `onClick`

JSX events get automatically delegated to the root React node. Actually, it goes a step further. It sets up a single event handler on the root node that handles all your events.

What does that mean? Normally when you attach event listeners directly to the element that the user interacts with, you end up with potentially many event listeners in memory for a single page. React creates a single listener automatically, so you never have to think about event delegation again.

This is really great for things like infinite scrolling, because you don’t have to worry about infinitely growing memory consumption (memory leaks).

It looks like DHTML from the 90's, but under the hood, it does the right thing.

TIP: Don’t make the body tag the root node for your React components. Other JavaScript on the page may alter the body tag, and React needs full control over its root element for event management.

Designers Don’t Mind JSX

Inline Styles Are Good

Putting styles in a React component is more akin to putting styles in a web component than putting styles into raw HTML. If you did it in raw HTML and you wanted to change the look of a buy button, and you have 10k items, you’d need to update the style in 10k places.

Components don’t work that way. Since the style is in the reusable component, you only have to update it in one place, and you don’t have to worry about selector scoping.

As a bonus, you also get style variables, style modules, style inheritance, and a number of other things you’re already using a preprocessor for — but now you don’t have to learn a whole new syntax. You do it in JS.

I thought I’d hate it, but I love it.

(The Right) Separation of Concerns

React doesn’t deal with data or business modeling. All it does is render stuff efficiently and delegate events. It knows the data it needs to render, it knows when to render it (when the data changes), and it knows how to render it efficiently. Similarly, it knows how to relay UI intentions back to the application.

What it doesn’t know is anything about what the application is doing with those user intentions, or what any of the data means to the business model or business rules.

If you’re putting business rules
in React components,
you’re doing it wrong.

I hid some things from you earlier. Let’s look at the complete component from above. This is a simple reusable component that displays an email address. When you click on the email address it switches to edit mode, which swaps the displayed email out for an HTML5 email input:

Notice there is no state anywhere in this file. The component doesn’t even know whether or not it’s using edit mode until you tell it with `props`. This is a stateless component.

Stateful components are an
anti-pattern in React.

Avoid `this.state`
and `setState()`.

Update: Anti-Pattern, Really?

“If a tree falls in the woods, does it make a sound? If a pure function mutates data to produce an immutable value, is that ok?” ~ @richhickey

In other words, as long as your state isn’t causing side-effects, maybe it’s OK. Still confused? I made you a flowchart.

One big exception to the state rule-of-thumb is container components. I use container components to integrate generic, reusable UI components into the specific state context of the application.

What are `props`?

You might also notice that the component doesn’t have any notion of what the event listeners are doing. I used a trick here that makes the component really easy to test and reuse in any app — I wrapped it in a factory function.

The factory allows you to pass in all the dependencies, including React. You could even pass in base styles if you wanted to, so your component can inherit standard styles from the rest of the app. In this case, I didn’t do that, but did pass in `setEmail()` and `setEditMode()` functions. In React / Flux lingo, those functions are called actions.

Actions communicate the user intentions to the app. This component doesn’t know anything about how your app listens for or responds to actions. It doesn’t know anything about how you store and manage state. All it knows is how to trigger those actions in order to communicate user intent.

It’s up to the app to take over from there.

Learn JavaScript app development
with Node, ES6 & React.

Preorder Now
for Lifetime Access to all
my JavaScript courses.

Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly), and “Learn JavaScript Isomorphic App Development with Node, ES6, & React”. He has contributed to software experiences for Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, and top recording artists including Usher, Frank Ocean, Metallica, and many more.

He spends most of his time in the San Francisco Bay Area with the most beautiful woman in the world.

JavaScript Scene

JavaScript, software leadership, software development, and…

JavaScript Scene

JavaScript, software leadership, software development, and related technologies.

Eric Elliott

Written by

Make some magic. #JavaScript

JavaScript Scene

JavaScript, software leadership, software development, and related technologies.