As Aurelia 2 draws near, I have made some changes to my blog. Acknowledging that many of you rely on my blog as a source of information and help with Aurelia 1, I have created an Aurelia 2 category and renamed the existing category to Aurelia 1.
This will hopefully alleviate any confusion that you might have when Aurelia 2 is released. While many of my Aurelia 1 articles will still be relevant, they might not always apply to the new version of Aurelia.
At the time of writing this post, TypeScript 3.7 is in beta. Eventually, this post will become irrelevant. But, for the moment if you are trying to get TypeScript 3.7 Beta or any of the RC builds working with Webpack and ts-loader you might have encountered a bunch of red text in your console.
In my case, I had target: "esnext" set in my tsconfig.json file which the ts-loader plugin should read and set the appropriate settings. And yet, TypeScript 3.7 Beta was not working despite making sure everything was up to date.
I am a huge proponent of Firebase and interestingly, up until recently, I had never used Firebase Storage. Instead, I usually opt for Amazon’s S3 service which I am familiar with. Wanting to keep everything in the one service is appealing to me, so I started to add in file upload functionality in a Firebase Cloud Function.
It was not as straightforward as I would have hoped. I am using Express with Firebase and the Google Cloud NPM package as documented in code examples and numerous tutorials.
Recently, I encountered an issue in Travis CI and my Aurelia application which uses Jest for the tests suite. I erroneously copied some older configuration code for Jest and used it in my Jest configuration, assuming it would work.
This error took a while to isolate and resolve. It was out of pure desperate that I accidentally discovered the fix. If I made the mistake, it is possible that you might as well. Does this sound familiar to you?
Wallaby.js is one of the most amazing additions you can make to your testing workflow. I have been a happily paid user for a couple of years now and if you are looking to up your testing game, I highly recommend it.
Chances are if you are reading this post, you already use Wallaby and you are looking to get it working in your Aurelia applications with Jest and TypeScript. It’s a combination that is not all too uncommon these days, TypeScript is the future.
The Aurelia Store plugin is a great way to add powerful and easy to use state management into your Aurelia applications. For some, the paradigm shift in how you work can be confusing to work with at first. One such task you might find yourself needing to do is obtaining a singular value from the state.
As you will soon discover, state management in Aurelia Store requires you to subscribe to the entire state and react to all changes. Sometimes you just want to get a single value from the state to reference inside of your view-models.
Being a parent, as any other parent would attest is rewarding, but hard work. And nothing has made modern parenting more challenging than YouTube.
We managed to not expose our firstborn son to any TV or screens until he was two. We were doing well until we had a trip booked from Australia to the UK, which was a 23-hour trip. We bit the bullet and bought an iPad to load up with some activities for the journey and some carefully selected YouTube videos.
If you are writing tests using Jest and you use TypeScript, there is a good chance you have encountered an error along the lines of TypeError: defaultsDeep_1.default is not a function or TypeError: myClass.default is not a constructor when trying to test a file that is using a default import from a module.
You most likely have read countless StackOverflow questions, but none of the solutions will solve the issue. You’ve read the Jest documentation (which is quite extensive), but still no mention of mocking default module imports with TypeScript.
A little over a year ago I took a new job and because the office is close to an hour and a half away, I wanted to work remotely for most of the week. Commuting upwards of three hours a day five times a week would have destroyed me.
So, while I don’t work 100% of the week remotely, I work two days in the office and three days at home. Everyone has their own experiences working remotely, and I thought it would be interesting to share my perspective and experience.
As ubiquitous as state management has become in front-end development, it is still a confusing magical black box to most developers. Data goes in, data goes out, and nobody thinks about what happens in-between.
Some developers believe the answer to the question in my title is: always. While some don’t believe in using state management at all and if you’re like me, the answer is: it depends.
When state management gets added to an application that meets the criteria for using it, a weight gets lifted off your shoulders, and things make sense. Prematurely introduce state management or use it in places where you shouldn’t, and your life becomes a tangled mess.