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.
Brewing with extract saves a heap of time and effort if you can’t afford the time and monetary investment in going the all-grain approach. The Coopers extract tins are fantastic, not only that but their website as a range of awesome recipes for using their cans, some even with inclusions of hops and additional cans of malt extract.
If you are new to brewing or perhaps want to improve your kit brews a bit, here is what I have learned. I am definitely not an expert, I am an amateur like you, but I have put down enough of these Cooper’s kits to know what works and what doesn’t.
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.
When it comes to adding in on-page functionality in the form of custom selects, autocomplete fields and more, jQuery UI is still an undisputed popular choice amongst some developers and using it within Aurelia is super simple.
Because Aurelia does not replace your HTML or parse it any differently than your browser does without Aurelia, it allows you to use any third party library or plugin inside of your Aurelia application without worrying about it messing with anything.
I have been a member of Wiselike for quite sometime now, before it was even called Wiselike I was a member of CareerDean which preceded it. I have been so busy that I kind of forgot about it until recently. I realised that a lot of people asked me questions and it is kind of addicting.
If you want to ask me anything, head on over to my Wiselike page and ask away. I am planning on being as active as I possibly can be. It is a good chance to not only ask code-related questions, but also my views on things and other stuff.
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.