As you’ve probably noticed by now, we’ve been using a lot of JSX. But we really haven’t taken a good look at what JSX actually is. How does it work? Why don’t we just call it HTML? What quirks does it have up its sleeve? In this chapter, we answer all those questions and more! We do some serious backtracking (and some forwardtracking) to see what we need to know about JSX in order to be dangerous.
One of the biggest things we’ve glossed over is trying to figure out what happens with our JSX after we’ve written it. How does it end up as the HTML that you see in the browser? Take a look at the following example, where we define a component called
We can quickly spot the JSX here. It’s the following four lines:
All of those neatly nested HTML-like elements, their attributes, and their children get turned into a series of
Notice that there’s no trace of JSX anywhere! All these changes between what we wrote and what our browser sees are part of the transpiling step we talked about in Chapter 1, “Introducing React.” That transpilation happens entirely behind the scenes, thanks to Babel, which we’ve been using to perform this JSX-to-JS transformation entirely in the browser. We’ll eventually look at using Babel as part of a more involved build environment in which we generate a transformed JS file, but you’ll see more on that when we get there in the future.
As we’ve been working with JSX, you’ve probably noticed that we’ve run into some arbitrary rules and exceptions on what we can and can’t do. In this section, let’s look at those quirks…and some brand new ones!
The values you return can be dynamically generated. All you have to do is wrap your expression in curly braces:
Notice that we’re throwing in a
Math.random() call to generate a random number. It gets evaluated along with the static text alongside it, but because of the curly braces, what you see looks something like the following: Boring 28.6388820148227 content!
These curly braces allow your app to first evaluate the expression and then return the result of the evaluation. Without them, you would see your expression returned as text: Boring Math.random() * 100 content!
That isn’t what you would probably want.
In a lot of our examples, we’ve returned one top-level element (often a
div) that then had many other elements under it. You aren’t technically limited to following that pattern: You can actually return multiple elements. And you can do that in two ways.
One way is to use an arraylike syntax:
Here we are returning three
p tags. They don’t have a single common parent. Now, when you return multiple items, you might or might not have to deal with one detail, depending on the version of React you are targeting. You need to specify a
key attribute and a unique value for each item:
This helps React better understand which element it is dealing with and whether to make any changes to it. How do you know whether you need to add the
key attribute? React tells you. You’ll see a message similar to the following printed to your Dev Tools Console: Warning: Each child in an array or iterator should have a unique “key” prop.
You also have another (and, arguably, better) way to return multiple elements. This involves something known as fragments. The way you use it looks as follows:
You wrap the list of items you want to return into a magical
React.Fragment component. Note a few cool things here:
1. This component doesn’t actually generate a DOM element. It is just something you specify in JSX that has no tangible existence when transpiled into the HTML your browser sees.
2. You aren’t treating what you are returning as items in an array, so you don’t need commas or anything separating each item.
3. There’s no need to specify a unique key attribute and value; this is all taken care of under the covers for you.
Before we leave this section, know that you can use a more condensed syntax instead of fully specifying
React.Fragment... like an animal. You can use just empty
This looks like something from the future, so if you’re inclined to use fragments to return multiple values, feel free to use this smaller syntax.
As you saw in Chapter 4, “Styling in React,” the
style attribute in your JSX behaves differently from the
style attribute in HTML. In HTML, you can specify CSS properties directly as values on your
In JSX, the
style attribute can’t contain CSS inside it. Instead, it needs to refer to an object that contains styling information:
Notice that we have an object called
} angle brackets to ensure that it is parsed as an expression:
Our comment in this case is a child of our
div element. If you specify a comment wholly inside a tag, you can just specify your single-line or multiline comment without having to use the
} angle brackets:
In this snippet, you can see an example of both a multiline comment and a comment at the end of a line. Now that you know all of this, you have one less excuse to not comment your JSX.
Capitalization is important. To represent HTML elements, ensure that the HTML tag is lowercase:
When you want to represent components, the component name must be capitalized:
If you get the capitalization wrong, React will not render your content properly. Trying to identify capitalization issues is probably the last point you’ll think about when things aren’t working, so keep this little tip in mind.
In many situations, your JSX won’t be neatly arranged inside a
return function as in the examples you’ve seen so far. Take a look at the following example:
We have a variable called
swatchComponent that is initialized to a line of JSX. When our
swatchComponent variable is placed inside the
Note: If you run into any issues, ask!
If you have any questions or your code isn’t running like you expect, don’t hesitate to ask! Post on the forums at https://forum.kirupa.com and get help from some of the friendliest and most knowledgeable people the Internet has ever brought together!