With the release of Aurelia 2 Beta 15, there are some important changes to be aware of regarding decorators. This update brings Aurelia 2 into compliance with the Stage 4 TC39 decorators proposal, resulting in significant differences in how decorators work compared to previous versions.
One notable change is that inline decorators for injection on constructors are no longer supported. For example, the following syntax is no longer valid:
constructor(@IApi readonly api: IApi, @IRouter private router: IRouter) { } Instead, to handle injection, you can define a class property and use the resolve function from the aurelia package. Here’s an example:
Once upon a console, in the deep, dark woods of an Aurelia 2 application, there was a developer who wanted to chop down the forest of confusion and carve out their own path with a custom logger. If you’re like this brave code-warrior, ready to leave the beaten track of default logging behind, then grab your virtual axe because we’re about to get crafty with some log-making magic!
First things first, let’s set up camp. Imagine your app as a cosy log cabin in the wilderness of the World Wide Web. You want to make sure that every creak of the floorboards (or, in this case, every line of code that executes) is heard loud and clear. But not just any old echo through the forest will do – you want your logging to be like the call of a majestic moose: distinctive, purposeful, and impossible to ignore.
Sometimes you have a request that doesn’t immediately return a response. For example, the user uploads some audio files and you process those and return them.
Using the Aurelia 2 Fetch Client, we are going to build an implementation that allows us to poll a specific endpoint and use callback functions to configure our response.
import { HttpClient } from '@aurelia/fetch-client'; export interface PollingOptions { pollingIntervalMs?: number; maxPollingAttempts?: number; isSuccess?: (response: Response) => boolean; parse?: (response: Response) => Promise; } export class PollingHttpClient { private readonly httpClient: HttpClient; private readonly defaultPollingIntervalMs = 1000; private readonly defaultMaxPollingAttempts = 10; constructor() { this.httpClient = new HttpClient(); } async pollUntilSuccess( url: string, options?: RequestInit, pollingOptions?: PollingOptions ): Promise { const pollingIntervalMs = pollingOptions?.pollingIntervalMs ?? this.defaultPollingIntervalMs; const maxPollingAttempts = pollingOptions?.maxPollingAttempts ?? this.defaultMaxPollingAttempts; const isSuccess = pollingOptions?.isSuccess ?? ((response) => response.ok); const parse = pollingOptions?.parse ?? ((response) => response.json() as Promise); let attempts = 0; while (attempts < maxPollingAttempts) { try { const response = await this.httpClient.fetch(url, options); if (isSuccess(response)) { return await parse(response); } } catch (error) { console.error('Fetch error:', error); } attempts++; await new Promise(resolve => setTimeout(resolve, pollingIntervalMs)); } throw new Error(\`Polling failed after ${maxPollingAttempts} attempts.\`); } } To use it, simply instantiate it like you would the ordinary Fetch client:
The Aurelia 2 Task Queue is a robust scheduler designed to address various challenges associated with timing issues, memory leaks, race conditions, etc. Unlike its predecessor in Aurelia 1, the Task Queue offers advanced control over synchronous and asynchronous tasks.
Comparison with Aurelia 1 While the term “task queue” may be familiar to those who have worked with Aurelia 1, it’s essential to recognise the fundamental differences in Aurelia 2. The new Task Queue is designed to prevent common challenges and offers enhanced capabilities and flexibility. In Aurelia 1, the task queue was notoriously known as something you used to execute code after rendering changes.
In Aurelia 2, lambda expressions bring a breath of fresh air to templating by enabling developers to write concise and expressive code directly within templates. A significant advantage of lambda expressions is that they allow developers to perform various operations without needing value converters, leading to cleaner and more maintainable code.
This article explores lambda expressions in Aurelia 2, emphasising filtering, sorting, and other operations that can be performed without value converters.
In modern web development, managing reactivity—how parts of an application respond to changes in data—is paramount. Aurelia 2, a robust JavaScript framework, introduces an elegant way to handle reactivity through effect-based observation. This guide will explore what effect-based observation is, why you might want to use it, and how to implement it in your Aurelia 2 applications.
What Are Effects? Effects are functions that are automatically re-run whenever specific dependencies change. These dependencies are often properties or variables accessed within the effect function. By utilising effects, developers can create a responsive system where functions are automatically invoked when the values they rely on are altered.
Aurelia 2, a modern front-end JavaScript framework, introduces a powerful feature called enhance that allows developers to breathe life into static HTML by binding Aurelia behaviours to existing DOM elements. If you worked with Aurelia 1, you might already be familiar with enhance functionality. This isn’t a new feature added to Aurelia.
What is enhance in Aurelia 2? The enhance function is a powerful feature of Aurelia 2 that provides a mechanism for developers to leverage the power of Aurelia within existing HTML pages. Essentially, it gives Aurelia the capability to enhance an existing DOM tree by associating Aurelia’s custom elements, custom attributes, or template controllers with the DOM nodes. This feature can be exceptionally useful in scenarios where a web page is partially server-rendered or when a DOM fragment needs to be added to the HTML document on the fly.
Custom web components have revolutionised web development by enabling encapsulation, reusability, and dynamic functionality. Combined with Aurelia 2, a robust and extensible framework, the possibilities for building rich, sophisticated applications are endless. A key feature of Aurelia 2 is its extensible Attribute Mapper, which bridges HTML attributes and JavaScript properties, enabling significant customization to meet unique application requirements.
Scenario: Custom Web Components Imagine developing an application that heavily utilizes custom web components, such as a custom slider element named , a custom dropdown (), and a custom date picker (). Each component has unique attributes that need to be bound to properties on your view models.
Aurelia 2, the latest incarnation of the Aurelia framework, is packed with improvements and new features. Among these, the revamped template compiler stands out for its potential to significantly boost your productivity. This article takes a deep dive into the template compiler, focusing on functionality that allows developers to intercept and modify the compilation process of an application’s templates.
Introduction to the Template Compiler Aurelia’s template compiler operates behind the scenes, processing templates and providing hooks and APIs that allow developers to modify their default behaviour. One critical use case for the template compiler is the ability to preprocess a template before it’s compiled. This could be for reasons such as accessibility validation, the addition of debugging attributes, or even the injection of custom attributes or elements.
In Aurelia 2 the @watch decorator allows you to react effectively to data changes in your application, from simple properties to complex expressions. Think of it as computedFrom (if you’re coming from Aurelia 1) but on steroids.
Basics of @watch The @watch decorator in Aurelia 2 lets you define a function that will execute whenever a specified expression changes. This expression can be a simple property on your view model, a custom attribute, or a more complex expression involving the view-models properties.