I have been working with Aurelia for a year now and loving it. I also discovered Wallaby earlier this year and love that as well. I got it to work when I was still using Jspm and System.js in my Aurelia application, but since moved over to Webpack. Because I am also using TypeScript, it complicated matters a bit getting Wallaby.js to work with Webpack and TypeScript. However, thanks to the help of Artem of Wallaby.js, I got it to work in the end.
This is a fun little plugin I wrote not long ago for being able to specify routes in JSON files and then load them into your Aurelia application. In my use-case recently I needed to define a bunch of routers and while I could have used child routers, at present child routers have limitations around things like triggering events and whatnot. I keep things simple by using top-level routes. As you can imagine, a simple application can grow into 10+ routes with ease, especially with an administration panel. This is why splitting routes into separate files can make your life easier, especially on a large team.
Well here goes nothin’. I am publishing a book on LeanPub on working with Aurelia. Initially I was working with a publisher to write a book on Aurelia, but the pressures of a strict schedule with a child under and full time job meant it did not work out. However, I really want to get something out there. So I felt Leanpub would be the best fit. I can write when I find the time, I can publish new chapters as I complete them and get feedback from customers throughout the process of the book.
I have been working with Aurelia and Node for a while now and recently I took the time to properly create an Aurelia Node.js starter skeleton and put it up on Github here. While getting Node.js to work with Aurelia is not exactly difficult, this is more of a time saving convenience. I have seen other solutions, but they feel a little hacky and structurally confusing. I adopted a Meteor approach in that all client logic is handled in the client folder and Node.js server logic is in the server folder.
When inside of an Aurelia ViewModel there are situations where you might want to know what the current route is within a ViewModel. One such scenario I encountered recently where I had one View and ViewModel pair being accessed by 5 different routes. I needed to know what route was accessing my ViewModel to load different data. This is what the second parameter of the activate method for. activate(params, navigationInstruction) { console.log(navigationInstruction); } The navigationInstruction parameter gives you the information about the route currently accessing the ViewModel. This allows you to access everything about the route, including the navModel
Update: December 12th, 2016 A lot has changed since this article was published. The bundling situation is a lot better and things have changed. While some of this article might still be applicable, please do your research and assume that parts of this article are no longer relevant. When it comes to Aurelia, one aspect that seems to trip up and confuse first timers and even seasoned developers is bundling.
At the time of writing this, the preferred approach to client side dependencies and loading is Jspm which is one part package manager and one part SystemJS loader polyfill. Although, we will be seeing other loader options in the near future such as Webpack and even a potential custom loader from the Aurelia team. But for now we have Jspm and System.js. Install the JSON loader for System.js We can use the JSON loader for System.js to load JSON files in our app in a bulletproof way. You can view the plugin here and see that it is really quite simple under the hood.
When it comes to the browser, queues are very important. The concept of a macrotask and microtask exist within the browser which allows standard tasks and micro tasks to be queued up. The Aurelia Task Queue dependency is not specific functionality to Aurelia itself, but rather wraps native browser methods and provides a fallback if you are not using a supported browser. The browser itself does not provide direct access to the microtask queue, but leveraging DOM Mutation Observers which use the microtask queue, you can tap into that powerful queue with relative ease (which is what this class does).
A little less publicised aspect of Aurelia is the UI Virtualisation plugin. For those accustomed to ReactJS’s speed of rendering large amounts of items in the DOM and offering high paint performance, this will be a welcome plugin to use. Although, do not be mistaken. The Aurelia UI Virtualization plugin is not meant to replace React, nor give you the same power that it offers. This is not a plugin for a virtual DOM, at least not at the time of writing this. For that, you will need to integrate and use React or an alternative.
When it comes to using a plain old event listener in your Aurelia applications, if you are not aware of how classes work and how things get transpiled, then you will most likely run into some issues working with events and scope. First you might try something like the following: export MyClass { attached() { document.addEventListener('click', this.handleBodyClick); } detached() { document.removeEventListener('click', this.handleBodyClick); } handleBodyClick(e) { console.log(e.target); } } On the surface everything looks fine, it should work right? Sorry, but this will not work. Many first timers implementing event listeners into their apps will run into this, heck I even ran into it once as well.