Earlier this week I asked people which piece of syntax they always find themselves Googling. My answer to that question was string literals in React (officially called template literals but we'll get to that).
What’s the piece of syntax that no matter how many times you use it you’ll always look it up?
For me it’s string literals in React.02:07 AM - 06 Aug 2020
In response, I got a lot of people asking questions. Aren't string literals an ES6 piece of syntax? Yes, they are.
What I should have said is that I always seem to mess up string literals INSIDE React. What's the difference? Let's talk about it!
"Just strings"
String literals are a concept with many names! You may have heard them referred to as template literals, template strings, and then my combined version 😅.
The long name for regular strings is “string literal”. However, due to the naming of template strings/template literals it’s gotten confused in modern conversations.
In some ways, string literals and strings can be the same thing. The following is considered a string literal.
const text = `some string`
That looks like it's a regular string. The only difference is that it's surrounded by backticks instead of quotation marks.
Multi-line strings
The reason this concept is more powerful than strings is because you can do more with it than the example above.
For instance, string literals allow for multiline strings.
const text = `some string line 1
and line 2 too`
How about an expression?
String literals are popular not necessarily because of the two use cases above, but because of the fact that you can include expressions in them.
const text = `some string ${expression}`
An expression can be a lot of things. Some kind of string or number manipulation logic. Or, more commonly, a variable.
let name = getName()
const fullName = `some string ${name}`
So how is it different in React?
Why does this confuse me in React? Arguably it shouldn't, it's the same ES6 syntax. The reason I always seem to mess it up in React is because you can't use a string literal directly when you pass it in a component.
<Component name=`some string ${name}`/>
The above code isn't valid. In order to use that string literal, you have to surround it with curly braces.
<Component name={`some string ${name}`} />
It's powerful code. Incredibly important and often used. But for me, it's one too many characters to remember.
And?
So I look it up! And maybe in the future, I'll look at this post instead. However, even if I can't write it off the top of my head it's invaluable to know what it is.
As with any piece of syntax, the more building blocks you know the more approachable it is to read code. It allows you to start to understand how the final codebase was put together.
Top comments (4)
Just to be clear, in ecmascript.
ecma-international.org/publication...
Otherwise you may end up confusing people. :)
We’re not good about consistent wording. You’ll see template literal and string literal used even if it isn’t the official wording in the spec. But yes, I tried to include the various terms since it’s confusing.
I would have named the post template literals but I was matching my original tweet.
TIL: React doesn't like template literals as a "string" prop.
Hi Laurie,
I teach and therefore switch a lot between different frameworks. What made me curious about this post is your thinking pattern. On a very high level, JSX has the very simple rule that interpreted (so JS) expressions or functionality is surrounded by curly braces in general.
<div className="my-class">is therefore hard-coded while
<div className={myClass}>interprets the value of the variable myClass. In pure ECMA you also wouldn't write it the way you described, but would likely have something like
So I guess my question is: On what basis would one think that the example without curly braces you provided should work? Is it based on your assumptions of how JSX works under the hood, or do you think it stems from working with other technologies prior to working with React?
This is probably an awkward question, but whenever I see my students doing things like that, I cannot explain why people think that markup is intuitive or the way it should work. Maybe you can shed some light ;-)