Friday, October 2, 2015

The Genius of Template Strings in ES6

ES6 is the future of JavaScript and it is already here. It is a finished specification, and it brings a lot of features a language requires to stay competitive with the needs of the web of now. Not everything in ES6 is for you, and in this little series of posts I will show features that are very handy and already usable.

If you look at JavaScript code I’ve written, you will find that I always use single quotes to define strings instead of double quotes. JavaScript is OK with either—the following two examples do exactly the same thing:

The reason why I prefer single quotes is that, first of all, it makes it easier to assemble HTML strings with properly quoted attributes that way:

The only time you need to escape now is when you use a single quote in your HTML, which should be a very rare occasion. The only thing I can think of is inline JavaScript or CSS, which means you are very likely to do something shady or desperate to your markup. Even in your texts, you are probably better off to not use a single quote but the typographically more pleasing ‘.

Aside: Of course, HTML is forgiving enough to omit the quotes or to use single quotes around an attribute, but I prefer to create readable markup for humans rather than relying on the forgiveness of a parser. We made the HTML5 parser forgiving because people wrote terrible markup in the past, not as an excuse to keep doing so.

I’ve suffered enough in the DHTML days of document.write, creating a document inside a frameset in a new popup window and other abominations, to not want to use the escape character ever again. At times, we needed triple ones, and that was even before we had colour coding in our editors. It was a mess.

Expression Substitution in Strings?

Another reason why I prefer single quotes is that I wrote a lot of PHP in my time for very large web sites where performance mattered a lot. In PHP, there is a difference between single and double quotes. Single-quoted strings don’t have any substitution in them, whereas double-quoted ones do. That meant back in the days of PHP 3 and 4 that using single quotes was much faster, as the parser didn’t have to go through the string to substitute values. Here is an example of what that means:

JavaScript didn’t have this substitution, which is why we had to concatenate strings to achieve the same result. This is pretty unwieldy, as you need to jump in and out of quotes all the time.

Multi-Line Mess

This gets really messy with longer and more complex strings and especially when we assemble a lot of HTML. And most likely you will sooner or later end up with your linting tool complaining about trailing whitespace after a + at the end of a line. This is based on the issue that JavaScript has no multi-line strings:

Client-Side Templating Solutions

In order to work around the mess that is string handling and concatenation in JavaScript, we did what we always do—we wrote a library. There are many HTML templating libraries, with Mustache.js probably having been the seminal one. All of these follow their own, non-standardized syntax and work in that frame of mind. It’s a bit like saying that you write your content in Markdown and then realizing that there are many different ideas of what “Markdown” means.

Enter Template Strings

With the advent of ES6 and its standardization, we can rejoice as JavaScript now has a new kid on the block when it comes to handling strings: Template Strings. The support of template strings in current browsers is encouraging: Chrome 44+, Firefox 38+, Microsoft Edge and WebKit are all on board. Safari, sadly enough, is not, but it’ll get there.

The genius of template strings is that it uses a new string delimiter, which isn’t in use either in HTML nor in normal texts: the backtick (`).

Using this one we now have string expression substitution in JavaScript:

The ${} construct can take any JavaScript expression that returns a value. You can, for example, do calculations, or access properties of an object:

That last example also shows you that multi-line strings are not an issue at all any longer.

Tagged Templates

Another thing you can do with template strings is prepend them with a tag, which is the name of a function that is called and gets the string as a parameter. For example, you could encode the resulting string for URLs without having to resort to the horridly named encodeURIComponent all the time.

This works, but relies on implicit array-to-string coercion. The parameter sent to the function is not a string, but an array of strings and values. If used the way I show here, it gets converted to a string for convenience, but the correct way is to access the array members directly.

Retrieving Strings and Values From a Template String

Inside the tag function you can not only get the full string but also its parts.

There is also an array of the raw strings provided to you, which means that you get all the characters in the string, including control characters. Say, for example, you add a line break with \n. You will get the double whitespace in the string, but the \n characters in the raw strings:

Conclusion

Template strings are one of those nifty little wins in ES6 that can be used right now. If you have to support older browsers, you can of course transpile your ES6 to ES5; you can do a feature test for template string support using a library like featuretests.io or with the following code:

Here are some more articles on template strings:

More Hands-On With JavaScript

This article is part of the web development series from Microsoft tech evangelists on practical JavaScript learning, open-source projects, and interoperability best practices, including Microsoft Edge browser and the new EdgeHTML rendering engine

We encourage you to test across browsers and devices including Microsoft Edge—the default browser for Windows 10—with free tools on dev.modern.IE:

In-depth tech learning on Microsoft Edge and the Web Platform from our engineers and evangelists:

More free cross-platform tools and resources for the Web Platform:


by Chris Heilmann via Tuts+ Code

No comments:

Post a Comment