Learning Aurelia

4.5 (2 reviews total)
By Manuel Guilbault
  • Instant online access to over 7,500+ books and videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Getting Started

About this book

Aurelia is one of the most promising new JavaScript frameworks for mobile, desktop, and web, which makes developing powerful, modern web applications a straightforward task. Its power lies in its simplicity and clear workflow that enables developers to build next-generations apps for the web with ease.

From initial structuring to full deployment, this book will serve as a step-by-step guide to develop a modern web application from scratch with the Aurelia framework. In addition to including a comprehensive coverage of various Aurelia framework features, this book will also show you how to utilize these features in the real world to develop a professional single-page web application. You’ll see how to make the most out of Aurelia by understanding the Aurelia workflow and then applying it in real-world development tasks. By the end of the book, you will have learned to develop a clean and maintainable application in Aurelia from scratch.

Publication date:
December 2016
Publisher
Packt
Pages
474
ISBN
9781785889677

 

Chapter 1. Getting Started

Developer experience is a key strength of Aurelia. Its authors paid careful attention to every aspect of the development process, so using the framework is seamless and fluid, and so the learning curve is as smooth as possible.

This book humbly attempts to follow the same philosophy. It will teach you how you can use Aurelia to build real-world applications from A to Z. In fact, while reading the book and following the code samples, that's exactly what you will do. You will start by setting up your development environment and creating the project, then I will walk you through concepts such as routing, templating, data binding, automated testing, internationalization, and bundling. We will discuss application design, communication between components, and integration of third parties. We will cover every topic most modern, real-world single-page applications require.

In this first chapter, we will start by defining some terms that will be used throughout the book. We will quickly cover some core Aurelia concepts. Then we will take a look at the core Aurelia libraries and see how they interact with each other to form a complete, full-featured framework. We will see also what tools are needed to develop an Aurelia application and how to install them. Finally, we will start creating our application and explore its global structure.

 

Terminology


As this book is about a JavaScript framework, JavaScript plays a central role in it. If you are not completely up-to-date with the terminology, which has changed a lot in the last few years, let me clear a few things up.

JavaScript (or JS) is a dialect, or implementation, of the ECMAScript (ES) standard. It is not the only implementation, but it is definitely the most popular. In this book, I will use the JS acronym to talk about actual JavaScript code or code files and the ES acronym when talking about an actual version of the ECMAScript standard.

Like everything in computer programing, the ECMAScript standard evolves over time. At the time of writing, the latest version is ES2016 and was published in June 2016. It was originally called ES7, but TC39, the committee drafting the specification, decided to change their approval and naming model, hence the new name.

The previous version, named ES2015 (ES6) before the naming model changed, was published in June 2015 and was a big step forward as compared to the version before it. This older version, named ES5, was published in 2009 and was the most recent version for six years, so it is now widely supported by all modern browsers. If you have been writing JavaScript in the last five years, you should be familiar with ES5.

When they decided to change the ES naming model, the TC39 committee also chose to change the specification's approval model. This decision was made in an effort to publish new versions of the language at a quicker pace. As such, new features are being drafted and discussed by the community, and must pass through an approval process. Each year, a new version of the specification will be released, comprising the features that were approved during the year.

Those upcoming features are often referred as ESNext. This term encompasses language features that are approved or at least pretty close to approval but not yet published. It can be reasonable to expect that most or at least some of those features will be published in the next language version.

As ES2015 and ES2016 are still recent versions, they are not fully supported by most browsers. Moreover, ESNext features have typically no browser support at all.

Those multiple names can be pretty confusing. To make things simpler, I will stick with the official names ES5 for the previous version, ES2016 for the current version and ESNext for the next version. But that's only my preference; in the following chapters, we may encounter some tools or libraries still using the original nomenclature.

Before going any further, you should make yourself familiar with the features introduced by ES2016 and with ESNext decorators, if you are not already. We will use these features throughout the book.

Note

If you don't know where to start with ES2015 and ES2016, you can find a great overview of the new features on Babel's website:

https://babeljs.io/docs/learn-es2015/

As for ESNext decorators, Addy Osmani, a Google engineer, explained them pretty well:

https://medium.com/google-developers/exploring-es7-decorators-76ecb65fb841

For further reading, you can take a look at the feature proposals (decorators, class property declarations, async functions, and so on) for future ES versions:

https://github.com/tc39/proposals

 

Core concepts


Before we start getting our hands dirty, there are a couple of core concepts that need to be explained.

Conventions

First, Aurelia relies a lot on conventions. Most of those conventions are configurable, and can be changed if they don't suit your needs. Each time we'll encounter a convention throughout the book, we will see how to change it whenever possible.

Components

Components are a first class citizen of Aurelia. What is an Aurelia component? It is a pair made of an HTML template, called the view, and a JavaScript class, called the view-model. The view is responsible for displaying the component, while the view-model controls its data and behavior. Typically, the view sits in an .html file and the view-model in a .js file. By convention, those two files are bound through a naming rule, they must be in the same directory and have the same name (except for their extension, of course).

Here's an example of an empty component with no data, no behavior, and a static template:

component.js

export class MyComponent {} 

component.html

<template> 
  <p>My component</p> 
</template> 

A component must comply with two constraints, a view's root HTML element must be the template element, and the view-model class must be exported from the .js file. As a rule of thumb, the only function that should be exported by a component's JS file should be the view-model class. If multiple classes or functions are exported, Aurelia will iterate on the file's exported functions and classes and will use the first it finds as the view-model. However, since the enumeration order of an object's keys is not deterministic as per the ES specification, nothing guarantees that the exports will be iterated in the same order they were declared, so Aurelia may pick the wrong class as the component's view-model.

The only exception to that rule is some view resources which we'll see in Chapter 3, Displaying Data, and Chapter 5, Making Reusable Components. In addition to its view-model class, a component's JS file can export things like value converters, binding behaviors, and custom attributes basically any view resource that can't have a view, which excludes custom elements.

Components are the main building blocks of an Aurelia application. Components can use other components; they can be composed to form bigger or more complex components. Thanks to the slot mechanism, you can design a component's template so parts of it can be replaced or customized. We will see all of this in the next chapters.

 

Architecture


Aurelia is not your average monolithic framework. It is a set of loosely coupled libraries with well-defined abstractions. Each of its core libraries solves a specific and well-defined problem common to single-page applications. Aurelia leverages dependency injection and a plugin architecture so you can discard parts of the framework and replace them with third-party or even your own implementations. Or you can just throw away features you don't need so your application is lighter and faster to load. We will look deeper into this plugin mechanism in Chapter 2, Layout, Menu, and Getting Familiar.

The core Aurelia libraries can be divided into multiple categories. Let's have a quick glance.

Core features

The following libraries are mostly independent and can be used by themselves if needed. They each provide a focused set of features and are at the core of Aurelia:

  • aurelia-dependency-injection: A lightweight yet powerful dependency injection container. It supports multiple lifetime management strategies and child containers.

  • aurelia-logging: A simple logger, supporting log levels and pluggable consumers.

  • aurelia-event-aggregator: A lightweight message bus, used for decoupled communication.

  • aurelia-router: A client-side router, supporting static, parameterized or wildcard routes, and child routers.

  • aurelia-binding: An adaptive and pluggable data-binding library.

  • aurelia-templating: An extensible HTML templating engine.

Abstraction layers

The following libraries mostly define interfaces and abstractions in order to decouple concerns and enable extensibility and pluggable behaviors. This does not mean that some of the libraries in the previous section do not expose their own abstractions besides their features. Some of them do. But the libraries described in the current section have almost no other purpose than defining abstractions:

  • aurelia-loader: An abstraction defining an interface for loading JS modules, views, and other resources.

  • aurelia-history: An abstraction defining an interface for history management used by routing.

  • aurelia-pal: An abstraction for platform-specific capabilities. It is used to abstract away the platform on which the code is running, such as a browser or Node.js. Indeed, this means that some Aurelia libraries can be used on the server side.

Default implementations

The following libraries are the default implementations of abstractions exposed by libraries from the two previous sections:

  • aurelia-loader-default: An implementation of the aurelia-loader abstraction for SystemJS and require-based loaders.

  • aurelia-history-browser: An implementation of the aurelia-history abstraction based on standard browser hash change and push state mechanisms.

  • aurelia-pal-browser: An implementation of the aurelia-pal abstraction for the browser.

  • aurelia-logging-console: An implementation of the aurelia-logging abstraction for the browser console.

Integration layers

The following libraries' purpose is to integrate some of the core libraries together. They provide interface implementations and adapters, along with default configuration or behaviors:

  • aurelia-templating-router: An integration layer between the aurelia-router and the aurelia-templating libraries.

  • aurelia-templating-binding: An integration layer between the aurelia-templating and the aurelia-binding libraries.

  • aurelia-framework: An integration layer that brings together all of the core Aurelia libraries into a full-featured framework.

  • aurelia-bootstrapper: An integration layer that brings default configuration for aurelia-framework and handles application starting.

Additional tools and plugins

If you take a look at Aurelia's organization page on GitHub at https://github.com/aurelia, you will see many more repositories. The libraries listed in the previous sections are just the core of Aurelia - the tip of the iceberg, if I may. Many other libraries exposing additional features or integrating third-party libraries are available on GitHub, some of them developed and maintained by the Aurelia team, many others by the community. We'll cover some of those additional libraries in further chapters, but I strongly suggest that you explore the Aurelia ecosystem by yourself after reading this book, as it is rapidly growing, and the Aurelia community is doing some very exciting things.

 

Tooling


In the following section, we will go over the tools needed to develop our Aurelia application.

Node.js and NPM

Aurelia being a JavaScript framework, it just makes sense that its development tools are also in JavaScript. This means that the first thing you need to do when getting started with Aurelia is to install Node.js and NPM on your development environment.

Note

Node.js is a server-side runtime environment based on Google's V8 JavaScript engine. It can be used to build complete websites or web APIs, but it is also used by a lot of front-end projects for  development and to build tasks, such as transpiling, linting, and minimizing.

NPM is the de facto package manager for Node.js. It uses http://www.npmjs.com  as its main repository, where all available packages are stored. It is bundled with Node.js, so if you install Node.js on your computer, NPM will also be installed.

To install Node.js and NPM on your development environment, you simply need to go to  https://nodejs.org/ and download the proper installer for your environment.

If Node.js and NPM are already installed, I strongly recommend that you make sure to use at least version 3 of NPM, as older versions may have issues collaborating with some of the other tools we'll use. If you are not sure which version you have, you can check it by running the following command in a console:

> npm -v

If Node.js and NPM are already installed but you need to upgrade NPM, you can do so by running the following command:

> npm install npm -g

The Aurelia CLI

Even though an Aurelia application can be built using any package manager, build system, or bundler you want, the preferred tool to manage an Aurelia project is the command line interface, a.k.a. the CLI.

At the time of writing, the CLI only supports NPM as its package manager and requirejs as its module loader and bundler, probably because they are both the most mature and stable. It also uses Gulp 4 behind the scenes as its build system.

CLI-based applications are always bundled when running, even in development environments. This means that the performance of an application during development will be very close to what it should be like in production. This also means that bundling is a recurring concern, as new external libraries must be added to some bundles in order to be available at runtime. We'll see this in detail in Chapter 10, Bundling for Production.

In this book, we'll stick with the preferred solution and use the CLI. There are, however, two appendices at the end of the book covering alternatives, a first for Webpack, and a second for SystemJS with JSPM.

Installing the CLI

The CLI being a command line tool, it should be installed globally, by opening a console and executing the following command:

> npm install -g aurelia-cli

You may have to run this command with administrator privileges, depending on your environment.

If you already have it installed, make sure you have the latest version, by running the following command:

> au -v

You can then compare the version this command outputs with the latest version number tagged on GitHub, at https://github.com/aurelia/cli/releases/latest.

If you don't have the latest version, you can simply update it by running the following command:

> npm install -g aurelia-cli

If for some reason the command to update the CLI fails, simply uninstall then reinstall it:

> npm uninstall aurelia-cli -g
> npm install aurelia-cli -g

This should reinstall the latest version.

 

The project skeletons


As an alternative to the CLI, project skeletons are available at https://github.com/aurelia/skeleton-navigation. This repository contains multiple sample projects, sitting on different technologies such as SystemJS with JSPM, Webpack, ASP .Net Core, or TypeScript.

Prepping up a skeleton is easy. You simply need to download and unzip the archive from GitHub or clone the repository locally. Each directory contains a distinct skeleton. Depending on which one you chose, you'll need to install different tools and run setup commands. Generally, the instructions in the skeleton's README.md file are pretty clear.

Those skeletons are other good starting points to begin a new application using different technologies. The two appendices at the end of this book show how to use some of them to build an application using either SystemJS with JSPM or Webpack.

Apart from those appendices, the rest of the book will keep using the CLI.

Our application

Creating an Aurelia application using the CLI is extremely simple. You just need to open a console in the directory where you want to create your project and run the following command:

> au new

The CLI's project creation process will start, and you should see something like this:

The first thing the CLI will ask for is the name you want to give to your project. This name will be used both to create the directory in which the project will live and to set some values, such as the name property in the package.json file it will create. Let's name our application learning-aurelia:

Next, the CLI asks what technologies we want to use to develop our application. Here, you can select a custom transpiler such as TypeScript and a CSS preprocessor such as LESS or SASS.

Note

The transpiler, little cousin of the compiler, translates one programming language into another. In our case, it will be used to transform ESNext code, which may not be supported by all browsers, into ES5, which is understood by all modern browsers.

The default choice is to use ESNext and plain CSS, and this is what we will choose:

The following steps simply recap the choices we made and ask for confirmation to create the project, then ask if we want to install our project's dependencies which it does by default. At this point, the CLI will create the project and run an npm install behind the scene. Once it completes, our application is ready to roll:

At this point, the directory you ran au new in will contain a new directory named learning-aurelia. This sub-directory will contain the Aurelia project. We'll explore it a bit in the following section.

Note

The CLI is likely to change and offer more options in the future, as there are plans to support additional tools and technologies. Don't be surprised if you see different or new options when you run it.

The path we followed to create our project uses Visual Studio Code as the default code editor. If you want to use another editor such as Atom, Sublime, or WebStorm, which are the other supported options at the time of writing, you simply need to select option #3 custom transpilers, CSS pre-processors and more at the beginning of the creation process, then select the default answer for each question until asked to select your default code editor. The rest of the creation process should stay pretty much the same. Note that if you select a different code editor, your own experience may differ from the examples and screenshots you'll find in this book, as Visual Studio Code is the editor that was used during writing.

If you are a TypeScript developer, you may want to create a TypeScript project. I however recommend that you stick with plain ESNext, as every example and code sample in this book has been written in JS. Trying to follow with TypeScript may prove cumbersome, although you can try if you like the challenge.

The structure of a CLI-based project

If you open the newly created project in a code editor, you should see the following file structure:

  • node_modules: The standard NPM directory containing the project's dependencies

  • src: The directory containing the application's source code

  • test: The directory containing the application's automated test suites, which we will explore in Chapter 7, Test all the Things

  • .babelrc: The configuration file for Babel, which is used by the CLI to transpile our application's ESNext code into ES5 so most browsers can run it

  • index.html: The HTML page that loads and launches the application

  • karma.conf.js: The configuration file for Karma, which is used by the CLI to run unit tests;

  • package.json: The standard Node.js project file

The directory contains other files such as .editorconfig, .eslintrc.json, and .gitignore that are of little interest for learning Aurelia, so we won't cover them.

In addition to all of this, you should see a directory named aurelia_project. This directory contains things related to the building and bundling of the application using the CLI. Let's see what it's made of.

The aurelia.json file

The first thing of importance in this directory is a file named aurelia.json. This file contains the configuration used by the CLI to test, build, and bundle the application. This file can change drastically depending on the choices you make during the project creation process.

Note

There are very few scenarios where this file needs to be modified by hand. Adding an external library to the application is such a scenario, which we will face multiple times in next chapters. Apart from this, this file should mostly never be updated manually.

The first interesting section in this file is the platform:

"platform": { 
  "id": "web", 
  "displayName": "Web", 
  "output": "scripts", 
  "index": "index.html" 
}, 

This section tells the CLI that the output directory where the bundles are written is named scripts. It also tells that the HTML index page, which will load and launch the application, is the index.html file.

The next interesting part is the transpiler section:

"transpiler": { 
  "id": "babel", 
  "displayName": "Babel", 
  "fileExtension": ".js", 
  "options": { 
    "plugins": [ 
      "transform-es2015-modules-amd" 
    ] 
  }, 
  "source": "src/**/*.js" 
}, 

This section tells the CLI to transpile the application's source code using Babel. It also defines additional plugins as some are already configured in .babelrc to be used when transpiling the source code. In this case, it adds a plugin that will output transpiled files as AMD-compliant modules, for requirejs compatibility.

There are many other sections in this file, some of which we will cover in further chapters, some others I've left for you to explore on your own.

Tasks

The aurelia_project directory contains a subdirectory named tasks. This subdirectory contains various Gulp tasks to build, run, and test the application. These tasks can be executed using the CLI.

The first thing you can try is to run au without any argument:

> au

This will list all available commands, along with their available arguments. This list includes built-in commands such as new, which we've used already, or generate, which we'll see in the next section along with the Gulp tasks declared in the tasks directory.

To run one of those tasks, simply execute au with the name of the task as its first argument:

> au build

This command will run the build task which is defined in aurelia_project/tasks/build.js. This task transpiles the application code using Babel, executes the CSS and markup preprocessors if any, and bundles the code in the scripts directory.

After running it, you should see two new files in scripts: app-bundle.js and vendor-bundle.js. Those are the actual files that will be loaded by index.html when the application is launched. The former contains all application code, and  both JS files and templates, while the later contains all external libraries used by the application including Aurelia libraries. We'll learn how to customize bundling in Chapter 10, Bundling for Production.

You may have noticed a command named run in the list of available commands. This task is defined in aurelia_project/tasks/run.js, and executes the build task internally before spawning a local HTTP server to serve the application:

> au run

By default, the HTTP server will listen for requests on port 9000, so you can open your favorite browser and go to http://localhost:9000/ to see the default demo application in action.

Note

If you ever need to change the port number on which the development HTTP server runs, you just need to open aurelia_project/tasks/run.js, and locate the call to the browserSync function. The object passed to this function contains a property named port. You can change its value accordingly.

The run task can accept a --watch switch:

> au run --watch

If this switch is present, the task will keep monitoring the source code and, when any code file changes, will rebuild the application and automatically refresh the browser. This can be pretty useful during development.

Generators

The CLI also offers a way to generate code, using classes defined in the aurelia_project/generators directory. At the of writing, there are generators to create custom attributes, custom elements, binding behaviors, value converters, and even tasks and generators, yes, there is a generator to generate generators.

Note

If you are not familiar with Aurelia at all, most of those concepts, value converters, binding behaviors, and custom attributes and elements probably mean nothing to you. Don't worry, we will cover these topics in the next chapters.

A generator can be executed using the built-in generate command:

> au generate attribute

This command will run the custom attribute generator. It will ask for the name of the attribute to generate then create it in the src/resources/attributes directory.

If you take a look at this generator which is found in aurelia_project/generators/attribute.js, you'll see that the file exports a single class named AttributeGenerator. This class uses the @inject decorator (which we'll see in more detail in Chapter 2, Layout, Menu, and Getting Familiar) to declare various classes from the aurelia-cli library as dependencies and have instances of them injected in its constructor. It also defines an execute method, which is called by the CLI when running the generator. This method leverages the services provided by aurelia-cli to interact with the user and generate code files.

Note

The exact generator names available by default are attribute, element, binding-behavior, value-converter, task, and generator.

Environments

CLI-based applications support environment-specific configuration values. By default, the CLI supports three environments-development, staging, and production. The configuration object for each of these environments can be found in the different files dev.js, stage.js, and prod.js located in the aurelia_project/environments directory.

A typical environment file looks like this:

aurelia_project/environments/dev.js

export default { 
  debug: true, 
  testing: true 
}; 

By default, the environment files are used to enable debugging logging and test-only templating features in the Aurelia framework depending on the environment. We'll see this in a next section. The environment objects can, however, be enhanced with whatever properties you may need. Typically, it could be used to configure different URLs for a backend, depending on the environment.

Adding a new environment is simply a matter of adding a file for it in the aurelia_project/environments directory. For example, you can add a local environment by creating a local.js file in the directory.

Many tasks, basically build and all other tasks using it, such as run and test expect an environment to be specified using the env argument:

> au build --env prod

Here, the application will be built using the prod.js environment file.

If no env argument is provided, dev will be used by default.

Note

When executed, the build task just copies the proper environment file to src/environment.js before running the transpiler and bundling the output. This means that src/environment.js should never be modified by hand, as it will be automatically overwritten by the build task.

The structure of an Aurelia application

The previous section described the files and folders that are specific to a CLI-based project. However, some parts of the project are pretty much the same whatever the build system and package manager are. These are the more global topics we will see in this section.

The hosting page

The first entry point of an Aurelia application is the HTML page-loading and hosting it. By default, this page is named index.html and is located at the root of the project.

The default hosting page looks like this:

index.html

<!DOCTYPE html> 
<html> 
  <head> 
    <meta charset="utf-8"> 
    <title>Aurelia</title> 
  </head> 
 
  <body aurelia-app="main"> 
    <script src="scripts/vendor-bundle.js"  
            data-main="aurelia-bootstrapper"></script> 
  </body> 
</html> 

When this page loads, the script element inside the body element loads the scripts/vendor-bundle.js file, which contains requirejs itself along with definitions for all external libraries and references to app-bundle.js. When loading, requirejs checks the data-main attribute and uses its value as the entry point module. Here, aurelia-bootstrapper kicks in.

The bootstrapper first looks in the DOM for elements with the aurelia-app attribute. We can find such an attribute on the body element in the default index.html file. This attribute identifies elements acting as application viewports. The bootstrapper uses the attribute's value as the name of the application's main module and locates the module, loads it, and renders the resulting DOM inside the element, overwriting any previous content. The application is now running.

Note

Even though the default application doesn't illustrate this scenario, it is possible for an HTML file to host multiple Aurelia applications. It just needs to contain multiple elements with an aurelia-app attribute, each element referring to its own main module.

The main module

By convention, the main module referred to by the aurelia-app attribute is named main, and as such is located under src/main.js. This file is expected to export a configure function, which will be called by the Aurelia bootstrapping process and will be passed a configuration object used to configure and boot the framework.

By default, the main configure function looks like this:

src/main.js

import environment from './environment'; 
 
export function configure(aurelia) { 
  aurelia.use 
    .standardConfiguration() 
    .feature('resources'); 
 
  if (environment.debug) { 
    aurelia.use.developmentLogging(); 
  } 
 
  if (environment.testing) { 
    aurelia.use.plugin('aurelia-testing'); 
  } 
 
  aurelia.start().then(() => aurelia.setRoot()); 
} 

The configure function starts by telling Aurelia to use its defaults configuration, and to load the resources feature, we'll see how features work in Chapter 2, Layout, Menu, and Getting Familiar. It also conditionally loads the development logging plugin based on the environment's debug property, and the testing plugin based on the environment's testing property. This means that, by default, both plugins will be loaded in development, while none will be loaded in production.

Lastly, the function starts the framework then attaches the root component to the DOM.

Note

The start method returns a Promise, whose resolution triggers the call to setRoot. If you are not familiar with Promises in JavaScript, I strongly suggest that you look it up before going any further, as they are a core concept in Aurelia.

The root component

At the root of any Aurelia application is a single component, which contains everything within the application. By convention, this root component is named app. It is composed of two files app.html, which contains the template to render the component, and app.js, which contains its view-model class.

In the default application, the template is extremely simple:

src/app.html

<template> 
  <h1>${message}</h1> 
</template> 

This template is made of a single h1 element, which will contain the value of the view-model's message property as text, thanks to string interpolation which we will explore more in details in Chapter 3, Displaying Data.

The app view-model looks like this:

src/app.js

export class App { 
  constructor() { 
    this.message = 'Hello World!'; 
  } 
} 

This file simply exports a class having a message property containing the string Hello World!.

This component will be rendered when the application starts. If you run the application and navigate to the application in your favorite browser, you'll see a h1 element containing Hello World!.

You may notice that there is no reference to Aurelia in this component's code. In fact, the view-model is just plain ESNext and it can be used by Aurelia as is. Of course, we're going to leverage many Aurelia features in many of our view-models later on, so most of our view-models will in fact have dependencies on Aurelia libraries, but the key point here is that you don't have to use any Aurelia library in your view-models if you don't want to, because Aurelia is designed to be as unobtrusive as possible.

Conventional bootstrapping

It is possible to leave the aurelia-app attribute empty in the hosting page:

<body aurelia-app> 

In such a case, the bootstrapping process is much simpler. Instead of loading a main module containing a configure function, the bootstrapper will simply use the framework's default configuration and load the app component as the application root.

This can be a simpler way to get started for a very simple application; as it negates the need for the src/main.js file you can simply delete it. However, it means that you are stuck with the default framework configuration. You cannot load features or plugins. For most real-life applications, you'll need to keep the main module, which means specifying it as the aurelia-app attribute's value.

Customizing Aurelia configuration

The configure function of the main module receives a configuration object, which is used to configure the framework:

src/main.js

//Omitted snippet... 
aurelia.use 
  .standardConfiguration() 
  .feature('resources'); 
 
if (environment.debug) { 
  aurelia.use.developmentLogging(); 
} 
 
if (environment.testing) { 
  aurelia.use.plugin('aurelia-testing'); 
} 
//Omitted snippet... 

Here, the standardConfiguration() method is a simple helper that encapsulates the following:

aurelia.use 
  .defaultBindingLanguage() 
  .defaultResources() 
  .history() 
  .router() 
  .eventAggregator(); 

This is the default Aurelia configuration. It loads the default binding language, the default templating resources, the browser history plugin, the router plugin, and the event aggregator. This is the default set of features that a typical Aurelia application uses. All those plugins will be covered at one point or another throughout this book. All those plugins are optional except the binding language, which is needed by the templating engine. If you don't need one, just don't load it.

In addition to the standard configuration, some plugins are loaded depending on the environment's settings. When the environment's debug property is true, Aurelia's console logger is loaded using the developmentLogging() method, so traces and errors can be seen in the browser console. When the environment's testing property is true, the aurelia-testing plugin is loaded using the plugin method. This plugin registers some resources that are useful when debugging components.

The last line in the configure function starts the application and displays its root component, which is named app by convention. You may, however, bypass the convention and pass the name of your root component as the first argument to setRoot, if you named it otherwise:

aurelia.start().then(() => aurelia.setRoot('root')); 

Here, the root component is expected to sit in the src/root.html and src/root.js files.

 

Summary


Getting started with Aurelia is very easy, thanks to the CLI. Installing the tooling and creating an empty project is simply a matter of running a couple of commands, and it takes typically more time waiting for the initial NPM install to complete than doing the actual setup.

In the next chapter, we'll go over dependency injection and logging, and we'll start building our application by adding components and configuring routes to navigate between them.

About the Author

  • Manuel Guilbault

    Manuel Guilbault is a Canadian-born, France-based developer, and works as the CTO of an online marketing startup. After studying software engineering in Montreal, he worked as a full-stack web developer for well-known clients in the press industry, automotive industry, and financial sector for 10 years.

    An Aurelia enthusiast since day one, he closely followed the development of the framework, while modestly contributing to it and blogging and talking about it. He is an active member of the Paris Aurelia meetup group.

    Passionate about software craftsmanship, agility, and lean principles, he loves to learn and debate about how we do things, why we do them this way, and how they can be improved.

    Browse publications by this author

Latest Reviews

(2 reviews total)
The content is excellent and easy to read. The author Guilbault really understands how Aurelia works. And the book cover is really nice too.
Great Introduction to Aurelia.
Book Title
Unlock this full book FREE 10 day trial
Start Free Trial