Template promises
Aurelia 2 enhances the handling of promises within templates. Unlike Aurelia 1, where promises had to be resolved in the view model before passing their values to templates, Aurelia 2 allows direct interaction with promises in templates. This is achieved through the promise.bind
template controller, which supports then
, pending
, and catch
states, reducing the need for boilerplate code.
The promise.bind
template controller allows you to use then
, pending
and catch
in your view, removing unnecessary boilerplate.
Basic Example
The promise binding simplifies working with asynchronous data. It allows attributes to bind to various states of a promise: pending, resolved, and rejected.
Promise Binding Using Functions
The following example demonstrates a method fetchAdvice bound to the promise.bind
attribute. It uses then
and catch
to handle resolved data and errors.
The i
variable triggers a method call in the template, as Aurelia considers method calls pure and re-invokes them only if their parameters change.
This example can also be seen in action below.
Promise Bind Scope
The promise
template controller operates within its own scope, preventing accidental pollution of the parent scope or view model.
In this example, data
and err
are scoped within the promise controller. To access these values in the view model, use $parent.data
or $parent.err
.
Nested Promise Bindings
Aurelia 2 supports nested promise bindings, allowing you to handle promises returned by other promises.
Promise Bindings with repeat.for
When using promise.bind
within a repeat.for
, it's recommended to use a let
binding to create a scoped context.
The above example shows usage involving repeat.for
chained with a promisify
value converter. Depending on the second boolean value, the value converter converts a simple value to a resolving or rejecting promise. The value converter in itself is not that important for this discussion. It is used to construct a repeat.for
, promise
combination easily.
The important thing to note here is the usage of let
binding that forces the creation of two properties, namely data
and err
, in the overriding context, which gets higher precedence while binding.
Without these properties in the overriding context, the properties get created in the binding context, which eventually gets overwritten with the second iteration of the repeat. In short, with let
binding in place, the output looks as follows.
Last updated