ES2015 introduced us to template strings and string interpolation. Everything you learned with string interpolation applies to Aurelia. You use the exact same syntax, which keeps things simple. Consider the following example:

In this example, we have created a template that has a single string interpolation reference to a property called “name”. When Aurelia renders this template, it will examine the corresponding view model to find a property called “name” and emit its value in place of the markup. If you happen to change the value of the “name” property later on, the template will be updated with the new value.

Let’s take a look at another example that has both string interpolation and data binding:

As we look at the preceding code sample, we see something that is new. It might not be familiar, as this syntax only belongs to Aurelia. The dot (.) notation identifies anything that will be used in the binding engine with Aurelia. Although this is new, it is still very straightforward, and you will find that it will be very easy to learn. Aurelia allows you to use the dot (.) notation with pretty much all attributes on an HTML element.

If we were to run the preceding sample , we would see that as soon as we start typing in the input, the change would be reflected in the paragraph element below.

You can also put conditional expressions in your string interpolation markup. This provides a lot of flexibility when you are building your template, as you can have it respond to properties off of your view model at runtime and dynamically change. Consider the following template:

Conditional expression inside your string interpolation can provide some very nice features in your application with very little coding.

Let’s move on to yet a little more complicated scenario.

You will find that as you begin writing your applications in Aurelia, you will create custom elements for code reuse and encapsulation. By creating a custom element, you will be able to reuse it multiple times in the same template and also across multiple pages. The logic and behavior that you code into the custom element will be repeated across all instances.

Let’s imagine that we want to create a welcome HTML page that references the preceding code example. We give this example the name “name-tag”. Now let’s create a new template and reference the “name-tag” custom element.

Again, we are using the same template syntax. We have introduced a new element called “require”. It is through this element that the Aurelia templating engine resolves dependencies and resources. The “require” simply states that it wants to use the “name-tag” custom element in the template. We then simply use the custom element by its referenced name inside our markup.

We have covered most of the basic scenarios when dealing with templates in Aurelia. There is one more concept that we need to cover that is not new to Aurelia, as it is part of the DOM standard.

Slots are part of the Shadow DOM specification. They are used to declare two separate DOM trees that can be merged together to produce a single visual rendered result. Consider the following example:

We have created a simple “panel” custom element and we have marked it using a slot so that any consumer of the custom element knows that they can provide their own content. Consider how a developer would use the “panel” custom element:

This should give you a good feel as to the power of the templating engine in Aurelia. Again, the learning curve should be minimal, as most of what we are presented belongs to a standards specification. Aurelia has been very careful to stay as close to the standards as possible when exposing its API.

There might be times where you would really like to use one template when a certain condition is true but another template when the condition fails. This is possible using the “compose” custom element provided by Aurelia. Consider that we have three separate templates we have created to handle for a greeting in the morning, afternoon, and evening. We will call them “morning”, “afternoon”, and “evening”, correspondingly. In our “welcome” template, we want to be sure to call the correct template based on the time. We could easily have a method that is called “getTemplate()”, and all it does is create a new instance of a Date object and determine the correct time and return the name of the correct template. Here’s what our template would look like:

You have the ability to bind not only to the “view” but also to the “view model” and “model” attributes on the “compose” custom element.

There are certain scenarios where HTML can be extremely rigid and it just doesn’t want you to put your markup where you want. The Table element is one of those candidates where it doesn’t like to have any other content except the exact elements it expects. This can be cumbersome if you are trying to build a library of reusable custom elements and you want to include table rows and columns. Not to worry, Aurelia has a mechanism to support this scenario. You use the “as-element” attribute on the element you want to have the contents swapped out with the view referenced in the attribute. Let’s look at an example:

Now, let’s look how we will use the “tr-view” view with our “table-view":

This feature was added mainly due to the way browsers are inconsistent with how they render certain HTML elements. By using this convention, we get a consistent solution that works across browsers.