The Event Aggregator is one of my favourite things about Aurelia and it is not even anything unique to Aurelia. There does not seem to be much info out there about it, probably due to its simplicity. But I have noticed people ask about it in the Gitter chat from time-to-time. At its core the Event Aggregator is a pub/sub layer for publishing and listening to actions that take place inside of your application loosely.
Plain old CSS is boring. If you are building your applications off of the Aurelia Skeleton Navigation then it ships with support for working with regular CSS. Adding in support for working with Sass in your Aurelia applications is as easy as whistling dixie. We are also going to be adding in support for Autoprefixer as well so we can automatically add in browser prefixes for all of our CSS without worrying about browsers like IE10 and what they can support.
In Angular 1.x you had the concept of a controller, directive, service, provider and other confusing terms to describe essentially what is one or two things. What is an Angular service An Angular service no matter how it was defined is a singleton. Every part of your application gets the same reference when it requests a service or factory. Angular services in Aurelia The concept of controllers, services, providers and factories does not exist in Aurelia. Everything is just an ECMAScript 2015 class with hints of future specification features like decorators thrown in for good measure. This works in our favour because porting an Angular service to Aurelia requires very little to no effort.
On a per route basis you might want to configure some additional route specific data that you can access in your view. For example a route might have an icon for your navigation menu. This actually came up in the Aurelia Gitter chatroom and I decided to do a quick little write up. Say hello to a little unknown property called settings Added all the way back in February 2015 when Aurelia was still a tiny blip on the Javascript radar was this property which allows you to define an object of additional properties for a route, similar to how Durandal does it.
Update March 2018: Two years on from the original publish date, Aurelia finally has support for server-side rendering. This means it is now possible to create isomorphic web applications in Aurelia that work with and without Javascript disabled, resulting in faster initial rendering speed. If you would like to see a working example, the Skeleton repo has you covered. Now, onto the existing article. Isomorphism is all the rage in the Javascript world. The server can return rendered HTML complete with pre-computation (converting bindings and templating specific events already taken care of increasing initial load speeds and time to paint quite substantially.
If you are like me, you browse Github for cool new repositories. My new hobby is looking at what the community are building for rival frameworks and one of those frameworks is Angular 2. The Angular 2 community has done a great job of porting over not only existing libraries from Angular 1, but also creating new ones. There are some that are not available for Aurelia, but fortunately there is quite a lot of overlap between the two frameworks in ECMAScript and TypeScript syntax.
In a single page application (SPA) like Aurelia, shared state is one of those important things every developer mostly encounters. Sharing the current state of a logged in user or sharing a shopping cart’s contents throughout the app. Fortunately, Aurelia makes it easy to build applications with shared state. By default a class in Aurelia is a singleton. If you create a service called UserService and inject it throughout different parts of your app, provided you’re injecting it without telling Aurelia to do anything non-standard, it will be a singleton.
While the default Aurelia convention of a view model looks for a matching HTML file in the same directory is what you want a lot of the time, sometimes you might want to load views from a centralised location like a views directory or ask the server to render you some HTML. In an application recently some components which have a bit of user-focused data in them populated by the server had to be implemented. I could have duplicated them, but it seemed to be a waste of code when I could render the Razor partials in my Aurelia application instead.
When it comes to progressively enhancing an application we already have enhance API which allows us to progressively enhance a page on first load, but what about enhancing a page with dynamically added elements after everything has loaded? Perhaps your application dynamically inserts HTML into your page. If you have experience working with AngularJS, you might be familiar with the ability to dynamically compile HTML using $compile which works for dynamically inserted HTML and other things that occur after the initial bootstrapping phase is done.
Recently in my Aurelia application I needed to handle some keypress events when the user hit the enter and escape keys. Fortunately Aurelia doesn’t abstract Javascript too much, so adding in keypress support is easy. You don’t really see things like this documented anywhere, so this is for my reference just as much as it is yours. export class SomeClass { constructor() { this.myKeypressCallback = this.keypressInput.bind(this); } activate() { window.addEventListener('keypress', this.myKeypressCallback, false); } deactivate() { window.removeEventListener('keypress', this.myKeypressCallback); } // This function is called by the aliased method keypressInput(e) { console.log(e); } } The best practice here is to ensure that the ViewModel has instantiated itself so we can register our event listener, then make sure in our deactivate method we remove the event listener to clean up memory usage.