App Tasks
App tasks provide injection points to run code at certain points in the compiler lifecycle, allowing you to interface with different parts of the framework and execute code.
Falling between component lifecycles and lifecycle hooks, app tasks offer injection points into Aurelia applications that occur at certain points of the compiler lifecycle. Think of them as higher-level framework hooks.
The app task API has the following calls:
creating
— Runs just before DI creates the root component - last chance to register deps that must be injected into the roothydrating
— Runs after instantiating the root view, but before compiling itself and instantiating the child elements inside it - good chance for a router to do some initial workhydrated
— Runs after self-hydration of the root controller, but before hydrating the child element inside - good chance for a router to do some initial workactivating
— Runs right before the root component is activated - in this phase, scope hierarchy is formed, and bindings are getting boundactivated
— Runs right after the root component is activated - the app is now runningdeactivating
— Runs right before the root component is deactivated - in this phase, scope hierarchy is unlinked, and bindings are getting unbounddeactivated
— Runs right after the root component is deactivated
You register the app tasks with the container during the instantiation of Aurelia or within a plugin (which Aurelia instantiates). In fact, there are many examples of using app tasks throughout the documentation. Such as MS Fast integration, building plugins, and the section on using the template compiler.
Many of Aurelia's own plugins use app tasks to perform operations involving registering numerous components and asynchronous parts of the framework.
Asynchronous app tasks
A good example of where app tasks can come in handy is plugins that need to register things with the DI container. The app task methods can accept a callback but also a key and callback, which can be asynchronous.
In the above example, we await importing a file which could be a JSON file or something else inside the task itself. Then, we register it with DI.
Another great example of using app tasks is the dialog plugin that comes with Aurelia. The deactivating
task closes all models using the dialogue service, as you can see here.
Registering app tasks
In Aurelia applications, app tasks are registered through the register
method and will be handled inside of your main.ts
file.
Within a plugin, the code is similar. You would be exporting a function which accepts the DI container as its first argument, allowing you to register tasks and other resources.
An app task example
Using code taken from a real Aurelia 2 application, we will show you how you might use App Tasks in your Aurelia applications. One such example is Google Analytics.
We then pass the GoogleAnalyticsTask
constant and register it with the container inside main.ts
The above code runs during the activating
app task and registers/attaches the Google Analytics SDK to our application.
Additional Examples
Dynamic Feature Loading based on User Roles
This example shows how to use an App Task for dynamically loading features based on user roles. It's particularly useful in applications with role-based access control.
In this example, during the activating phase, the application checks the user's roles and dynamically imports features based on these roles.
Global Error Handling Setup
Setting up a global error handler during the creating
task ensures that any uncaught errors in the application are handled in a unified manner.
This example uses the creating
task to set up a global error handler that intercepts and processes uncaught errors.
Application Telemetry Setup
This example demonstrates setting up application telemetry using an App Task, which is useful for gathering usage metrics.
Here, the hydrated
task initializes and starts a telemetry session after the application is hydrated.
Last updated