Kind of a strange post from what I usually post, but the last few months I have been addicted to entering online competitions.
The fact I have won a few great prizes in just a few months probably helps. I won a runner up prize which was an LG television and then I won a Weber Baby Q Titanium barbecue. I also scored a free double pass to see the movie Office Christmas Party complete with free drink and popcorn. The movie wasn’t that great, but it was a night out for me and my wife.
Firebase Cloud Functions are great, but there might come a time where you need CORS support. This can be enabled easily by using the CORS middleware.
The documentation does detail part of the process, but it doesn’t mention you need to install the cors package and also specify origin: true as a configuration option. If you’re new to Node.js, this might catch you off guard.
Go into your functions directory in your application and in your terminal: npm install cors --save this will add the CORS middleware package to your package.json.
Because Firebase is a NoSQL JSON data store, you might have noticed that when you get some data from Firebase that it is an object. If the title wasn’t obvious enough, we are talking about using Firebase Realtime Database in a web application.
Take the following example:
firebase.database().ref('/posts').on('value', function(snapshot) { console.log(snapshot.val()); }); Let’s imagine that we have 20 posts in our database. You’ll get back an object containing keys and objects for all of our imaginary posts.
If you’re using the latest and greatest Webpack plugin for Aurelia, there is a possibility if you use the element to dynamically render UI you will run into an issue where Webpack doesn’t know about the dynamic imports.
Specifically, I am talking about usage of that might look like the following:
This is due to the fact, they can’t be resolved beforehand and put into the bundle. Fortunately, there is an easy fix for all of this.
The flexibility of Aurelia means there are many ways to achieve a task. The default convention of view/view-model will meet your needs a lot of the time, but sometimes you might need a little more power.
You might already know of the ability to define views inline (inside of your view-models) using the inlineView decorator, allowing you to eschew view HTML files entirely. The InlineViewStrategy class offers similar functionality for a different purpose.
Most of the time when you’re looping over an array of elements, you’ll do it sequentially. However, I recently needed to iterate through an array of objects in reverse just using a plain old for loop.
This will not be a highly informative or groundbreaking post but, I thought I’d share this in case someone wants to solve the same problem and might be confused with the many different ways you can loop over an array in reverse.
If you’re a TypeScript user and you’re reading this, then you’re using TSLint (most likely). Recently, a situation at work arose where even though TSLint warnings were being thrown in the editor as well as terminal output, some developers (tsk tsk) were still committing these warnings.
Naturally, a pre-commit Git hook is the right candidate for this. Being able to run TSLint to ensure that before a developer can even commit let alone push, only valid code conforming to the tslint.json file can be pushed.
A few people have actually asked me this question, so I thought a helpful blog post for reference would finally answer the question: What’s the difference between static inject and @inject in Aurelia?
The answer will surprise you. Okay, not really. It’s a pretty clear-cut answer. There is no difference between either.
Back in the early days of Aurelia before support for decorators was added (we are talking early 2015 here), you did things a little more verbosely because support for decorators was non-existent.
As many of you know, I have been working on an in-progress book on Aurelia titled Aurelia For Real World Applications for quite a while now.
Good news! the book is finally nearing its release and I’ve actually started working on the example applications chapter (amongst the others still in progress). This is probably the most anticipated chapter of the entire book for many readers.
One of those applications is a Markdown Editor that you can see running here. Shortly, owners of the book will be able to obtain the source code to this application and numerous other apps.
In this article we won’t be detailing how to setup a new Webpack application, but how you can leverage code splitting to reduce the size of your application.
If you would like to know how to create a new Webpack application capable of supporting code splitting, this post has you covered.
This will be a rather quick post, no advanced concepts to learn or remember here.
What is code splitting? It’s a fancy term describing how you can break parts of your application into smaller Javascript bundles. Instead of having one massive Javascript file that contains your application and dependencies, you take parts of your app and split it into smaller files (sharing the load).