Recently whilst helping out a client with an Aurelia TypeScript project, I encountered a situation where the latest development version of TypeScript 2.0 was being used, but some of the newer features like filesGlob support were not being picked up. Module resolution and other things were also an issue.
Turns out you can configure Visual Studio Code to use a local version of TypeScript through a setting directive inside of a project settings file.
One of the lesser known abilities of Aurelia is that every Aurelia element has an au property on it. This means if you query the DOM for an Aurelia element, it will have an au property which contains app and controller.
While this is really handy to know, in most cases if you are a Chrome user, then the Aurelia Context plugin for Chrome is probably a safer bet as it integrates into the Chrome developer tools.
Even though I primarily use Webpack for a massive Aurelia project I am working on, I am doing a fun internal project at work and decided to try out the Requirejs based Aurelia CLI. Not only is it fast, but incredibly easy to get a project setup from scratch without worrying about the messiness of using a skeleton.
One issue I encountered with trying to use Lodash with my Requirejs based project was simply importing it inside of my template wasn’t enough. It wasn’t being included in the bundle. Because Lodash in particular installed via Npm has no dist folder or real main entry, you need to tell the CLI where to find the right file.
After over a year of hard work from the community and Aurelia team, the framework I and many others have grown to love has finally hit RC.
What does this mean? The framework is maturing. After a lengthy beta, Aurelia is almost ready for the primetime. This means you can now comfortably use Aurelia in production, even though many of us have been doing so since mid 2015.
A new exciting addition is the Aurelia CLI which will simplify getting new Aurelia projects up off the ground without needing to worry about the skeletons (although the skeletons will be sticking around).
Even though I have moved onto Webpack sometime ago in Aurelia, lately I have been partly driven by frustration over how buggy things are with Webpack support in Aurelia at the moment, so I decided to see if Jspm 0.17 would work with Aurelia.
Without delving into unnecessary details, I got a skeleton setup with Aurelia and Jspm 0.17. Check it out here.
There is one remaining issue and that is the Aurelia Bundler is broken. This means bundling does not currently work with this skeleton. However, I am looking into a bundling solution that might not even need the plugin and just use the Jspm builder directly. Watch this space.
One of the biggest upcoming additions to Javascript (in my opinion) is support for async/await. If you have worked with a language like C# before, then you will immediately know why async/await is fantastic.
Currently async/await is in stage 3 which means it is almost a completed specification. At the time of writing this post, surprisingly Microsoft’s Edge browser is the only browser which has added in support for async/await.
Support alert:
While async/await will soon be standardised into the TC39 specification by the end of 2016 (hopefully) you still need to use a transpiler like Babel to add in support. At the time of writing this, TypeScript lacks support for async/await, so you need to use Babel with it.
Anyone who’s tried homebrewing in many parts of Australia (I am in Queensland) knows it’s a battle against the elements. Scorching temperatures and stifling humidity can make it incredibly tough to maintain consistent fermentation temperatures.
As any brewer will tell you, temperature control is key to producing quality beer. For a long time, I struggled with this, especially since I’m an extract brewer working without a dedicated temperature-controlled fridge. Enter the Cool Brewing Bag—a simple yet ingenious solution that has completely transformed my brewing experience.
This is one of those daily occurences I see in the official Aurelia Gitter chatroom (not a member, come say hello here).
You are using a bindable in your application to add in binding, whether it be one-way, two-way or one-time. You might define your bindable inside of your custom element viewmodel like this:
import {bindable} from 'aurelia-framework'; export class MyNameCustomElement { @bindable someNameValue = ''; } One would naturally assume that to use this attribute, you would reference it like this:
Even if you are new to Aurelia, you are probably familiar with the @bindable functionality which allows you to add bindable attributes primarily to your custom elements and custom attributes.
There is a lesser known feature in Aurelia in the form of @observable which allows you to use the underlying observation layer in Aurelia to observe variables for changes and react accordingly in a similar way you react to changes on @bindable attributes.
Sometimes you want to specify in your application multiple allowed values. For example, you might have a method which allows you to perform server requests and the only allowed values are; GET, POST, UPDATE, DELETE and PUT.
Ideally you want to prevent any developer from calling a method with an invalid value. Normally you would use an enum for this, most languages support the use of an enum which might be used for this purpose.