The first entry point of an Aurelia application is the main HTML page-loading and hosting.
aurelia-app
attribute helps us to introduce our entry point, themain.ts
file, which includes the configurations of the project.
In Aurelia 2, it is a little different, you need to call your root component (<my-app>
in this example) but
What happened to aurelia-app
?
There is noaurelia-app
in Aurelia 2. Themain.ts
file will detect via the project configuration.
All the initial settings for starting and working with an Aurelia project are done in this file.
What does PLATFORM.moduleName
do?
Whenever you reference a module by string, you need to usePLATFORM.moduleName("moduleName")
to wrap the bare string. PLATFORM.moduleName
is designed to teachWebpack
about Aurelia's dynamic loading behavior.
What is a globalResources
?
When you create a view in Aurelia, it is completely encapsulated so you mustrequire
components into an Aurelia view. However, certain components are used so frequently across views that it can become very tedious to import them over and over again. To solve this problem, Aurelia lets you explicitly declare certain "view resources" as global.
What is a feature
?
Sometimes you have a whole group of components or related functionality that collectively form a "feature". This "feature" may even be owned by a particular set of developers on your team. You want these developers to be able to manage the configuration and resources of their own feature, without interfering with the other parts of the app. For this scenario, Aurelia provides the "feature".
What is a plugin
?
Similar to features, you can install 3rd party plugins. The main difference is that a "feature" is provided internally by your application, while a plugin is installed from a 3rd party source through your package manager.
What does setRoot()
do?
Instantiates the root component and adds it to the DOM.
One of the best and most exciting changes has been made in this section.
What happened to PLATFORM.moduleName
?
Aurelia 2 works with any bundler without limitation or specific configuration so I'm sure you guessed it, you don't need PLATFORM.moduleName("moduleName")
anymore.
Is globalResources
still supported?
Yes, Any component or class you add to the applicationregister()
will be globally accessible through DI.
How can I have a plugin
?
If you are creating aplugin
, then the usual practice is to export
a configuration object. That can be registered in the client code. As a best practice, we recommend an alternate approach to registering each component individually in this way. Instead, create a folder where you keep all your shared components. In that folder, create a registry.ts
module where you re-export your components. Then, import that registry module and pass it to the application's register method at startup.
For example:
What happened to feature
?
This is conceptually similar toplugin
so you can do the same for internal use.
Where is the setRoot()
?
The app()
method is equivalent of the setRoot()
.
The root of any Aurelia application is a single
component, which contains everything within the application, actually, the root component.
To import any style, component or etc, you should userequire
.
Wrapping the whole HTML content viatemplate
isnecessary
.
Unlike version 1, There is a convention for loading your CSS file when the name is the same as the component, just like my-app.css
, so you don't need to import it manually.
To import any style, component or etc you should use import
. An alternative to require
in version 1. By default, the components you create aren't global. What that means is that you can't use a component within another component, unless that component has been imported.
Wrapping the whole HTML content via template
is optional
.
Every component instance has a life-cycle that you can tap into. This makes it easy for you to perform various actions at particular times
constructor
constructor
✗
define
✗
✗
hydrating
✗
✗
hydrated
✗
✗
created
created
✗
binding
bind
✓
bound
✗
✓
attaching
✗
✓
attached
attached
✓
detaching
✗
✓
unbinding
unbind
✓
dispose
✗
✗
Aurelia 1 has a restriction and the community made an afterAttached plugin that is called after all child components are attached, and after all two-way bindings have completed. Theattached
life-cycle in version 2 covers this scenario.
Which life-cycle hooks are most used?
Such cases can be summarized.
binding
Fetch data (working with API services & Ajax calls), initialize data/subscriptions.
bound
Any work that relies on fromView/twoWay binding data coming from children, Defining router hooks.
attached
Use anything (like third-party libraries) that touches the DOM.
unbinding
Cleanup data/subscriptions, maybe persist some data for the next activation.
dispose
One way cleanup all the references/resources. This is invoked only once and is irreversible
A dependency injection container is a tool that can simplify the process of decomposing such a system. Oftentimes, when developers go through the work of destructuring a system, they introduce a new complexity of "re-assembling" the smaller parts again at runtime. This is what a dependency injection container can do for you, using simple declarative hints.
container.createChild()
DI.createContainer()
-
container.registerSingleton(key: any, fn?: Function)
Registration.singleton(key: any, value: Function): IRegistration
-
container.registerTransient(key: any, fn?: Function)
Registration.transient(key: any, value: Function): IRegistration
-
container.registerInstance(key: any, instance?: any)
Registration.transient(key: any, value: any): IRegistration
-
container.registerHandler(key, handler)
Registration.callback(key: any, value: ResolveCallback): IRegistration
-
container.registerResolver(key: any, resolver: Resolver)
container.registerResolver(key: any, resolver: IResolver)
-
container.autoRegister(key: any, fn?: Function
✗
-
✗
Registration.alias(originalKey: any, aliasKey: any): IRegistration
-
container.get(MyService)
container.get(MyService)
-
✗
container.getAll(MyService)
-
@singleton
✓
-
@transient
✓
-
@inject(MyService)
@inject(MyService)
-
@autoinject()
✗
@inject(Lazy.of(MyService))
@inject(lazy(MyService))
-
@inject(All.of(MyService))
@inject(all(MyService))
-
@inject(Optional.of(MyService))
@inject(optional(MyService))
-
@inject(Parent.of(MyService))
✗
-
@inject(Factory.of(MyService))
@inject(factory(MyService))
-
@inject(NewInstance.of(MyService))
@inject(newInstanceForScope(MyService))
-
✗
@inject(newInstanceOf(MyService))
-
Writing debug output while developing is great. This is how you can do this with Aurelia.
Write an appender.
In the main(.js|.ts)
You can register LoggerConfiguration
as following
Usage
How to write an appender
?
How to write a sink
?
How to register appender
and sink
into the Aurelia container?
Finally, The usage
canActivate
if the component can be activated.
activate
when the component gets activated.
canDeactivate
if the component can be deactivated.
deactivate
when the component gets deactivated.
canLoad
canActivate
✓
loading
activate
✓
canUnload
canDeactivate
✓
unloading
deactivate
✓
${ }
✓
one-way
✓
to-view
✓
from-view
✓
two-way
✓
one-time
✓
bind
✓
| Name | Aurelia 1 | Aurelia 2 | Description | | ---- | - | - | | ref | ✓ | ✓ | | | view-model.ref | ✓ | ✓ | deprecated in v2 | | component.ref | ✗ | ✓ | Not in v1 |
call
✓
trigger
✓
delegate
✓
capture
✓
{% hint style="info" } In v2, if an expression return a function, that function will be use as the handler for the event. V1 only evaluates the expression. {% endhint }
General
$this
✓
The view-model that your binding expressions are being evaluated against.
Event
$event
✓
The DOM Event in delegate
, trigger
, and capture
bindings.
Repeater
$parent
✓
✓
$parent.$parent.$parent.name
✓
✓
$index
✓
✓
$first
✓
✓
$last
✓
✓
$even
✓
✓
$odd
✓
✓
$length
✗
✓
@computedFrom
tells the binding system which expressions to observe. When those expressions change, the binding system will re-evaluate the property (execute the getter).
✓
✗
In Aurelia 2, The framework automatically computes observation without the need for any configuration or decorator.
property
${a}
syntax:
✓
✓
observation:
✓
✓
member
${a.b}
syntax:
✓
✓
observation:
✓
✓
value conveter
${a | convert: value }
syntax:
✓
✓
observation:
✓
✓
binding behavior
${a & behavior: config }
syntax:
✓
✓
observation:
✗
✗
function call
${doThing(param)}
syntax:
✓
✓
observation:
✓
✓
array methods
${items.join(', ')}
syntax:
✓
✓
observation (on array):
✗
✓
lambda
${items.filter(x => x.v > 70)}
syntax:
✗
✓
observation:
✗
✓
This feature is totally new for Aurelia 2.