Welcome to the last section of this chapter! You can consider yourself a full stack programmer with strong knowledge on frontend technologies. If you note, the concepts that Aurelia uses to implement the different features are based on common problems that every web application needs to deal with, no matter which framework it is using. Also, as open source tools, the different plugins are based on other tools that actually give support to other framework plugins, such as Angular.

Now, the last feature that we will explain is about computed properties. We can resume it in a single line:

Computed properties are those that are preprocessed on the ViewModel layer in a JavaScript function.

Let's see a very simple practical use—you are developing a page that shows the ${firstName} and ${lastName} as a single value—${completeName}.

A common solution should create a JavaScript function to concatenate both values and map it into a ViewModel property. This is valid, but Aurelia comes with a better solution—the aurelia-computed plugin. This improves the efficiency of data-binding computed properties.

Do you remember the getter/setter function we mentioned in the first chapter? Well, it's time to use them.

This plugin uses Aurelia's JavaScript parser to parse the body of the property's getter function and check the result for observability purposes. If the getter function is observable, a specialized observer is returned to Aurelia's binding system. The observer publishes change events when properties accessed by the getter function change.

Let's look at an example:

// "firstName" and "lastName" will be observed.
get completeName() {
  return `${this.firstName} ${this.lastName}`;
}

There's nothing special yet. This function is using dirty-checking to bind the completeName computed property.

Why dirty? It's because the observer strategy wont be waiting for any change performed in the two values needed to retrieve the completeName property. It means the getter function will be executed many times across your component life cycle. Should we consider it as an issue? Really no, but if your application is becoming bigger and you have many computed properties, your performance could be directly impacted. So, what's Aurelia's solution? Just one annotation—@computedFrom:

import {computedFrom} from 'aurelia-framework';

    export class User {
      firstName = 'Diego';
      lastName = 'Arguelles';

      @computedFrom('firstName', 'lastName')
      get completeName() {
        return `${this.firstName} ${this.lastName}`;
      }
    }

Aurelia's binding system will observe the specified properties and reevaluate bindings when any of the properties change. The aurelia-computed plugin simply automates the dependency identification and is able to support more complex scenarios such as observing property paths.

Another common use for this feature is to retrieve the current logged user data. We can define a Boolean property to tell our component whether the user is logged in or not, and based on this, show the real username or just Visitor:

// "isLoggedIn", "user" and "user.userName" will be observed.
@computedFrom('userName')
get userName() {
  return this.isLoggedIn ? this.userName : '(Visitor)';
}