I have been working with Aurelia Store these past few months and at one point, I decided that it would be a great idea to write a book on how to leverage the Aurelia Store plugin in your Aurelia applications.
I have been writing on and off for a while and the book now has enough content in it, that I am ready to announce the book. The book is just over 40% complete and keeping in line with how LeanPub operates, the book is a constant work in progress that will be published often. At present, I am publishing once per day.
If you’re new to state management or you’re familiar with it and not using Aurelia Store already (you should), today we are going to be looking at how you can integrate Aurelia Store into your Aurelia applications and make the life of your development team and yourself a lot less stressful.
A lot of state management articles will wheel out the TV and VCR player on the tray table with wheels and default to the cliche shopping cart or todo application example to show you how to work with state management.
If you are new to Aurelia or perhaps already building something with it, here are some tips and tricks I have learned over the last two years which have helped me write well-performing Aurelia applications.
Keep in mind that Aurelia is like any other framework or library and that it is very easy to write poor performing applications if you’re not careful. Never assume that a framework will stop you from writing bad code.
Let’s acknowledge the elephant in the room, if you’re a reader of my blog then you would know that I am a huge Aurelia fan and user. I’ve been working with Aurelia since February 2015, so 3.5 years now (wow).
I am on the Aurelia core team, I have contributed to the community through plugins/skeletons, answering questions on StackOverflow and I regularly do Aurelia consulting/freelance work (hire me). There is a good chance you’re reading this blog post because you’re familiar with my many previous Aurelia blog posts over the years.
As many of you know, I love working with Aurelia and I love working with Firebase. I have been combining both of these together to create personal projects for a while now.
Newly introduced server-side rendering also strengthens my toolbelt with the ability to quickly spin up new Aurelia applications without having to worry about configuration and tooling.
This is why I have open sourced my Aurelia Firebase SSR Skeleton on Github. A starter for creating Aurelia applications, think of it as being similar to the skeleton applications Aurelia currently offers, but more up-to-date and easier to work with.
One of my favourite Aurelia changes isn’t a new feature, nor is it a long-awaited bug fix or new tool: it’s the fact the CLI now supports Webpack by default.
Why is this a big deal? Previously, the CLI took a RequireJS first approach to bootstrapping new applications, meaning if you didn’t choose to customise your au new generated application, you would get RequireJS as your default bundler.
Now, there isn’t anything wrong with RequireJS as a bundler, but the issue with RequireJS is given its age there are issues dealing with different file formats, especially styles and static assets like images and fonts (which it cannot handle).
I have been asked this question a few times and it can be hard to see things from the perspective of a newcomer to Aurelia, given how long I have been working with it. What is obvious to me is not obvious to everyone else.
When you’re deciding to build an Aurelia application, you’ll discover there is a CLI tool called Aurelia CLI and on Github, a collection of different skeleton applications for building an Aurelia application (preconfigured with testing, some routes and other logic).
The answer to this isn’t scientific, you should choose the CLI. The skeletons are representative of a time when Aurelia didn’t have a CLI, when it was still in alpha, beta and release candidate stages.
When you are building an Aurelia plugin and you want to test it, you will want to use npm link or yarn link to create a local symbolic link to your module and then use it in a test application.
If you are working with Aurelia and Webpack, then you’ve probably run into an issue with linked Node modules can’t resolve files correctly. You might have some code in your plugin that looks like this in an index.js / index.ts.
Did you know Aurelia introduced an else attribute a while ago which allows you to do if/else statements in your views complete with support for animation?
If you have been working with Aurelia for more than a few months, then you probably have been working with if/else statements by using multiple if.bind attributes in your HTML or using a terniary inside of string interpolation curlies. But, the else attribute allows us to write cleaner HTML without the need for multiple if statements doing the inverse of one another.
I have been waiting for this day to come for a long time now: the Aurelia CLI now supports scaffolding Webpack applications from scratch.
My biggest gripe with the skeletons the Aurelia team provide is they have a lot of stuff in them I have to remove for every new project.
Admittedly, the skeletons serve to showcase how a functional Aurelia application could look like — but make a lot of assumptions on things like using a router or Fetch to make HTTP requests.