In Aurelia 1, you could debug and identify Aurelia applications based on specific attributes in the dom. In Aurelia 2, the default setting for compiled HTML is to strip away Aurelia framework attributes.
What this means is if you need to debug your HTML, see what custom attributes are being passed to a custom element, and so on, you won’t see anything.
Like everything in Aurelia, you can customise this. Inside your main.ts file, you can set debug mode to true to bring back the Aurelia specific HTML attributes and markup.
In Aurelia 1, we had the children decorator which allows you to query HTML elements inside of a component and then access them. In Aurelia 2, we have a children decorator, but it works differently.
We are going to assume for this article that we have a bunch of custom elements being rendered called product-block which represent detail blocks for products in our custom element view
In Aurelia 1 @children('product-block') productBlocks; Simple and effective.
In Aurelia 2, we have a couple of different ways of working with slotted content. If you are familiar with Web Components, the slot element is a placeholder that can have content projected into it, the common use for this is reusable components.
In Aurelia 1, we had support for the slot element and could project almost anything we wanted inside of it, but there were limitations (as per the spec) which meant it wasn’t always the best tool for the job.
About a year or so ago in the internal Aurelia core team chat, I raised an idea for inferred bindings. A lot of the time I find myself binding to values that have the same name as the bindable property.
The idea is simple, say I have a custom element that has a bindable property called products, I would then most likely do something like the following:
It has always felt a bit redundant to me that I am specifying a property and then more often than not passing in a value of the same name. Well, after raising this again in the Aurelia core team chat, I was shocked to discover that this has been implemented.
One of my favourite additions to Aurelia 2 is proper support for Shadow DOM and with it, the ability to encapsulate my styles on a per-component basis, it works well most of the time. However, if you’re using a CSS library such as Bootstrap or legacy CSS, you will need to add in some global CSS styling.
Fortunately, Aurelia makes it easy to add in shared CSS styles. In-fact, if you use npx makes aurelia to create a new Aurelia 2 application and choose Shadow DOM, it automatically adds some code into main.ts which allows you to add shared CSS styles.
In Aurelia 2, despite the framework itself being completely overhauled and rewritten, many aspects of the framework remain the same familiar Javascript framework many of us know and love. What is new is the router in v2, it works differently to v1 in many aspects.
The router can work a few different ways. The first being the new direct-routing functionality which allows you to route to components without having to write any route configuration code. I love the direct router, which you can read more about here in the official Aurelia 2 docs.
At the time of writing this, Aurelia 2 is almost about to have its alpha release. Even so, if you’re reading this in the future and I have forgotten to update this post, everything here should still apply (some of the configuration options might change).
Fortunately, Aurelia 2 makes creating a new application from scratch easy. You can use Webpack, TypeScript, Babel and choose the way you write CSS and testing strategies as well (Jest, Cypress, etc).
If you’re like me, in Aurelia 1 you configured the Fetch client with some defaults, usually inside of your main bootstrap code (main.js/main.ts) where you might have added an authorization header, set up a default base URL and other configuration options you wanted to be global for the fetch client.
While there are other ways you can approach configuring the fetch client globally, I wanted to approach it in the same way you would if you were creating an Aurelia 2 plugin. This approach will also allow us to test it easier (testing is beyond the scope of this post).
With Aurelia 2, everything has been reimagined from the ground up. While the syntax and way you build applications is largely the same as Aurelia 1, there are some key differences and one of those is lifecycles.
When I say lifecycles I am talking about component lifecycles and router lifecycles. If you need a handy reference for what lifecycle you should use, you just found it.
This will not cover all lifecycle methods, just the ones that most people would want to know about such as dom attached and where you should load data from an api.
Buy the Aurelia 2 book here.
With the Aurelia 2 alpha coming very shortly, I have had plans for a while to write another Aurelia book, this time around on Aurelia 2. I learned a lot writing my first book and admittedly, made a few mistakes. The learning experience was invaluable.
With my first book, it came at a time when the Aurelia documentation was subpar. The book served as more of a stand-in for the lack of detailed and concise documentation. With Aurelia 2, extensive documentation work has been undertaken to the point where a book telling you about every little thing makes no sense.