wp-content/uploads/2016/01/PBS_Logo.png

Templating is a very important concept to get to grips with as you move from web pages to web apps. You need the ability to design some generic HTML and then easily inject data into it. Every UI popup has a standard form, but the information being displayed changes each time its invoked. Similarly, apps often use some kind of card interface to show a collection of similar items, those are basically the same piece of HTML being re-used with different data over and over again. Clearly, you want to be able to easily create a template for one card, and then re-use it over and over again.

I’ve been trying to find the perfect moment to insert this topic into the series, and it struck me that Bootstrap Toasts would make a simple but informative example around which to introduce the topic. So far we’ve been generating toasts by building them up piece-by-piece with jQuery, starting with a tag, setting the text, setting some attributes and properties, adding some classes, appending tags together, and so on. The code works, but it’s cumbersome to write, and worse still, difficult to debug and maintain. Hopefully you’ve been thinking to yourself ‘there must be a better way?’, because if you have been, you’ll be very well motivated to ingest this instalment!

You can download this instalment’s ZIP file here.

PBS 71 challenge Solution

The challenge set at the end of the previous instalment was quite simple — improve the simple timer web app created as the PBS 70 challenge by adding visual feedback to show the user that a timer is running, and, allow the timer to be canceled. The UI design was entirely at your discretion!

The approach I chose to take is to transform the start button into a cancel button with a spinner.

Before starting to add new functionality I started by re-factoring my solution to PBS 70 a little. To make the event handlers easier to read I first moved the code for starting a timer into a separate function named startTimer(). For this function to be able to access my shortcut variables to the various parts of the UI it needs to share a scope with those variables. This is why I created the function within the jQuery document ready handler, and not out in the global scope. The actual code for the function is simply cut-and-pasted from the submit handler for the form:

The form’s submit hander can then be updated to simply become:

Next I broke the code for enabling and disabling the form out into stand-alone functions. Again, I defined them within the jQuery document ready handler so they share a scope with my helper variables:

Again, the relevant parts of the startTimer() function were updated to call these new helper functions.

As things stand, the button on my form is a submit button, and the event handler starting the timer is on submit. To get my button to work as both a start and cancel button it needs to be transformed into a regular button with a click handler. From a markup point of view this simply involves changing the type from submit to button. To make the button easier to address I also gave it an ID:

Rather than replacing the submit handler, I chose to add a click handler. Why? Because while the visual page no longer has a submit button, many browsers and assistive devices offer various shortcuts for submitting forms, and those should still have the expected result, i.e., the timer should start.

To make things easier, I first created another utility variable for addressing the button:

The I added the click handler:

Up to this point we’ve not actually changed any functionality, we’ve simply re-factored the code so it does the same thing in a slightly different way. These changes will make it easier to implement our changes though.

Before we update the code for the button to add the spinner and to change the text as appropriate I chose to lay some foundations. Specifically, to add support for two CSS utility classes; running_only, and not_running_only. The idea is that anything with these classes will be shown or hidden as appropriate when the timer starts and ends.

To do this I updated the disableForm() and enableForm() functions as shown:

With that groundwork laid we can finally update the button’s markup to include a spinner and two separate textual labels:

At this stage we have a working solution to the first part of the challenge — our form now clearly indicates its running state to the user. However, having the button remain green seems inappropriate, so I updated the disableForm() and enableForm() functions to toggle the button between green (btn-success) and red (btn-danger):

Let’s tackle the final part of the challenge now, giving users the ability to cancel a running timer. Before we plumb in some UI, let’s start by writing a function that will actually stop a timer. Like all our other functions, it needs to share a scope with my utility variables, so I’ve created it within the jQuery document ready event handler:

At this stage we’re almost ready to plumb this new functionality into our form, we just need to make one more preparatory change. As things stand, the button is disabled when the form is disabled, that means it can’t be clicked, so it can’t stop the timer!

To fix this I updated the $formControls utility variable so it no longer includes buttons:

Finally, we can now update the click hander on the button to start or stop the timer as appropriate:

At this stage we have a working solution, but it would benefit form a little re-factoring. As things stand there’s a lot of code duplication between the timeout that fires when the timer ends, and the stopTimer() function. This can be easily fixed by replacing the duplicated code in the timeout with a call to the stopTimer() function:

With that we have what I consider to be a perfect solution to the challenge. You’ll find my complete code in the folder pbs71-challenge-solution in this instalment’s ZIP.

Introducing Templates

Templating is an extremely broad topic — templates come in many forms, and they fill many different needs in many different ways. While I haven’t focused on the word, we have been making extensive use of one form of JavaScript templates throughout most of the JavaScript-focused instalments in this series. Strings defined within back-ticks are officially *Template literals* (formerly *Template strings*). Using the ${} operator we can inject data into these strings:

We just mixed data (the variable like) with static content (the strings "I really like " & ", it's just so tasty!").

However, that type of templating doesn’t get us to where we need to be with re-usable UI snippets. Template literals save us from horrible string concatenations, but they don’t save us from the kind of ugly code we’re currently using to create Toasts!

HTML was originally designed to be a markup language for hyperlinked text documents, not to be a markup language for interactive apps with complex UIs. Over time the web has moved from the original read-only paradigm to the modern so-called *Web 2.0* read/write paradigm. That meant that HTML4 was being used for things it was never designed to be used for, and the short-comings were obvious. HTML5 was intended to address many of those shortcomings. We’ve already seen that in action with the new HTML 5 form elements and HTML 5 form validation, and we’ll shortly discover that HTML 5 also tried to tackle the problem of re-usable UI snippets. In other words, HTML 5 provides us with another form of templating.

As nice of an addition as the HTML5 templates are, they fall a long way short of being a panacea, so in JavaScript, like in so many other languages, there are myriad (not literally 10,000, but many!) 3rd-party JavaScript templating libraries out there. They all have their strengths and weaknesses, and there is no such thing as a one true JavaScript templating library! We are going to pick one, but think of it as an illustration of the kind of functionality templating libraries provide, rather than as any kind of suggestion that it is somehow the best or the one you must or even should use!

If HTML5 has templating support, why doe these other libraries exist? There are many reasons, but they include the fact that many of these templating libraries work in IE, while HTML5 templates don’t, that many of these libraries existed before HTML5 was released, and the fact that these libraries generally offer functionality above and beyond what HTML5 gives you. Also, some of these libraries exist across different languages, so you can write a template once, and use it in apps written in multiple languages.

Finally, we developers are human, we have preferences, so we’ll love some templating libraries because they gel well with our way of thinking, and we’ll hate others because they do things in ways we don’t like. It’s not just about logic and reason, there’s also just plain old love and hate!

Having said all that, the templating library I’m currently using in my day-to-day work is Mustache, and that’s the one we’ll use in this series. The reasons I like it are that it’s cross-language, covering both of the languages I program in regularly (JavaScript and Perl), it’s light-weight (not too complicated, and not too big of a codebase), and I like how it looks! Just to underline the point again, I’m not implying Mustache is the best JavaScript templating library, it’s just the one that fits me needs and wants best, and since its the one I know, it’s the one I’m going to teach 🙂

The HTML5 <template> Tag

Let’s start our journey into templating by looking at what HMTL5 gives us out-of-the-box without resorting to a third-party templating library.

The <template> tag allows you to define clone-able snippets of HTML within an HTML document that are not considered to be a part of the document by the browser. This means that the templates are not just visually invisible, but their contents is not see by the DOM query functions, and hence, not by 3rd-party libraries like jQuery either.

If you have a template that contains a <div> with the class toast inside an HTML 5 template and you query the document for all <div>s with the class toast, the <div> inside the template will not be in the set of results returned by jQuery.

To use an HTML5 template you ask the browser to create a clone of the template’s contents. To do this you need a reference to the raw DOM object representing the template. The easiest way to facilitate that is to give your templates IDs.

Also note that template tags can’t appear just anywhere in your code, you should add them as direct children of either the <body> or <head> tags.

Let’s consider the following sample template:

First, we need to get a reference to the raw DOM object representing our template. We can do this using the built-in JavaScript function document.getElementById():

This is one of the native functions that jQuery users under the hood to do its magic. Since this is a part of core JavaScript it does not return a jQuery object, but a raw DOM object direct from the browser. The argument is an ID as a string. Note that function does not expect a CSS selector, hence no # prefixed to the ID.

We can also make use of jQuery’s .get() function to access the template’s raw DOM object:

We can now access the template’s contents using the DOM object’s .content property, and we’ll need to clone it using the built-in JavaScript function document.importNode():

When we clone the template’s contents the output will be a so-called document fragment. We don’t want the fragment itself, instead, we want its contents, and we can get those via the fragment’s .children property:

After all that we’ll be left with a raw DOM object representing a clone of the contents of the template. If we were using native JavaScript DOM functions we could manipulate this object directly, but we’ve been learning jQuery, so we need to convert this DOM object into a jQuery object by passing it to jQuery’s $() function:

Putting it all together we can get a jQuery object representing a clone of our template with:

We can of course collapse all that down into a single line:

We can now manipulate this jQuery object in the normal way, for example, we can inject text into the span with the class .thing with:

And we would then inject it into our document in the normal jQuery way (with .append(), .prepend(), .before(), or .after()).

A HTML5 Template Example — An Updated Toast Generator

In this instalment’s ZIP file you’ll find pbs72a.html. This is a stripped-down version of pbs70b.html (from instalment 70) with just a single form remaining, the one for generating toast notifications.

We’re going to refactor this code so it uses HTML5 templates to generate the toasts rather than building them up piece-by-piece with jQuery.

Before we start, this is how the code currently builds up the toast:

The highlighted lines are where the structure of the toast get defined. I think it’s fair to say it’s very difficult to tell at a glance what that the resulting HTML would look like.

We can replace that un-glanceable code with this much clearer template:

With that done, we can re-write the event handler:

I’ve highlighted the changes from the original in pbs72a.html.

Rather than building up the Toast tag-by-tag we simply cloned the template, then injected the text into the header and body of the toast.

You can see the finished refactoring in pbs72b.html in this instalment’s ZIP file.

Note that you can use this file to prove to yourself that template content is not really part of the document, but separate from it. Open the file in a browser, refresh the page, and do not generate any toasts. Open the JavaScript console, and search for all tags with the class .toast:

Notice that despite the fact that the template contains a <div> with the class .toast, the $() function returns an empty set.

A Challenge

Using either your own solution to the previous challenge, or the sample solution above as your starting point, update the timer app to use an HTML5 template for the toast notifications.

Final Thoughts

This has been our first introduction to templating, and already we have a powerful mechanism for creating dynamic content without having to build it up piece-by-piece with jQuery. In the next instalment we’ll take things to the next level with an introduction to the third-party templating library Mustache.