If you’re like me, you’ve worked with Angular a lot or you are currently working with Angular and over time you have grown accustomed to its very concepts; controllers, directives, factories, providers and services. In Aurelia those concepts can exist, but not in the way you think.
If you’re thinking of porting over an Angular 1.x application to Aurelia, below we will touch upon various concepts to make the transition as easy and seamless as possible.
There will not be any code comparison, this article assumes you have opted to choose Aurelia for your next or current application and you come from an Angular background, wanting to understand new concepts.
Directives
One of the things I really hated about Angular is the confusing directive syntax. A directive can be both an attribute or element. In Aurelia they’re not called directives, we have two separate types we can choose: Custom Attributes or Custom Elements.
Factories/Providers/Services
In Angular we have all of these confusing ways of creating singletons; providers, factories, services and resources. In Aurelia a ViewModel/class is presumed to be singleton by default. We even have the option of declaring it as transient as well. Read more here about Aurelia’s dependency injection.
Controllers
Nope. There are no controllers in Aurelia. All you have is a ViewModel that is rendered either by the router or some other part of your application. Aurelia is not an MVC framework.
Filters
In Aurelia the concept of filters does exist, except they’re more aptly named value converters. As you can see here the syntax is almost the same. Porting over Angular filters to Aurelia should be a breeze.
Binding & Templating
If you’re porting an Angular application, this part will be the most important. Understanding how Aurelia deals with displaying and binding to values in a view opposed to Angular.
Templating
Keeping inline with ECMAScript 2015 templating, all Aurelia HTML template views require <template></template>
tags to properly acknowledge themselves as views.
Expressions & Strings
In Angular we used double curly braces to display values and perform expressions inside of our HTML. Because Aurelia utilises ECMAScript 2015/2016 specifications, we can use string interpolation instead.
In most cases simply retraining your brain to use ${}
instead of {{}}
is all you need to remember when working with Aurelia. You can read more about string interpolation via the official Australia documentation.
Language
In Angular we have; ngClass, ngHide, ngInclude, ngRepeat, ngSrc and so on. In Aurelia there are counterparts to these features found in Angular.
- ngClass –
class="${myClassString}"
- ngClick –
click.trigger="function()"
orclick.delegate="function()"
- ngHide –
show.bind=""
- ngInclude –
<require from=""></require>
- ngRepeat –
repeat.for="item of items"
- ngSrc –
src.bind=""
Databinding
In Angular we had the likes of ngModel, ngValue and other bindings for working with form input values. In Aurelia we still have this concept, the API however is easy to understand use.
One Way Binding
By default .bind
will assume a “one-way” binding relationship for all attributes, with exception of form element values which use “two-way” binding by default.
In Angular to achieve one-way binding, we need to use something like ngValue
to prevent a two way relationship or ngChange
One Time Binding
A one-time binding means that a value is not bound at all, there is no observation happening. The value is just printed into the page as is and any future changes will not update the value.
In Angular we have the confusing {{::myVar}}
and in Aurelia we have a more verbose value.one-way=""
Two Way Binding
All form elements in Aurelia are presumed to be “two-way” bindings. Any non form elements are presumed to be “one-way” bindings by default. However, given Aurelia offers a verbose way of binding, we can simply use: value.two-way=""
and we have two way binding.
Conclusion
As you can see Aurelia simplifies your workflow. From working with databinding, to templating and custom expressions. The lack of abstraction means you spend less time scratching your head and more time coding.
If something did not make sense or I missed an important aspect of Angular that should have its equivalent covered in Aurelia, leave a comment below or drop me an email.
Thanks for the insights. I have one question: how do one “port” the Controller to Aurelia?
This link is broken: http://eisenbergeffect.bluespire.com/binding-with-value-converters-in-aurelia/
which is a pity because I was looking for help on this exact subject.