Dzulqarnain Nasir

Migrating from WebpackDevMiddleware to SpaServices.Extensions

Upgrading to .Net Core 3.x resulted in some breaking changes for my front-end development process, in particular the Hot Module Reloading (HMR) feature that I use in all my projects.

If you use the WebpackDevMiddleware, it’s likely you would have seen this message pop up after upgrading to .Net Core 3.

So, what do we do now?

Getting Storybook to work with Vuetify 2.0

This is just a short post regarding how I got Storybook to play nicely with Vuetify after upgrading to Vuetify 2.0.

As most of you already know, Vuetify 2.0 recently came out. That’s awesome, but it also came with a few breaking changes, the primary of which is their move towards making Vuetify a Vue plugin, which had to be bootstrapped to the primary Vue instance.

This is fine and all, except it broke my Storybook build.

Azure Functions + Node.js + TypeScript + Webpack

I’m a big TypeScript fan. If my blog posts and GitHub projects haven’t already made that clear, I’m now putting that on record.

So when I found out that the latest azure-functions-core-tools now comes with the ability to create a Functions app in TypeScript out of the box, I got excited.

In this post, I’d like to share my experience setting up an Azure Functions App project for Node.js in TypeScript, with Webpack for generating the app bundles.

Webpack-ing static content for TypeScript

Here’s a quick one.

I’ve recently started cleaning up the code for one of my projects, and one of the things I did was introducing the file-loader plugin, and converting static content references throughout my codebase.

It was a pretty straightforward process for image URLs within my Vue files, but then I also have code that switches out the background image of elements based on specific conditions. This requires the static content URL to be imported into the code that handles the logic.

For example:

// component class

get centerOverlayStyle() {
    let backgroundImage = null;

    if (this.inputMode === MapInputMode.PICKUP) backgroundImage = 'url(/public/static/pickup-icon.svg)';
    if (this.inputMode === MapInputMode.DROPOFF) backgroundImage = 'url(/public/static/dropoff-icon.svg)';

    return { backgroundImage };
}

In order for me to use the image files emitted by file-loader, I need to replace the image paths with the ones generated by the plugin.

According to the documentation, I can simply import the image file into my code, and assign it to a local variable, and use it whenever I need reference to the image URL anywhere in my code. file-loader would resolve the path, allowing my code to point to the correct URL.

import pickupIcon from '@/static/pickup-icon.svg';
import dropoffIcon from '@/static/dropoff-icon.svg';

// component class

get centerOverlayStyle() {
    let backgroundImage = null;

    if (this.inputMode === MapInputMode.PICKUP) backgroundImage = `url(${pickupIcon})`;
    if (this.inputMode === MapInputMode.DROPOFF) backgroundImage = `url(${dropoffIcon})`;

    return { backgroundImage };
}

Unfortunately, while this works for regular JavaScript, TypeScript sees this as a problem.

Cannot find module '@/static/pickup-icon.svg'.
Cannot find module '@/static/dropoff-icon.svg'.

TypeScript assumes that everything we import are modules, and if it cannot determine this to be the case, it will log an error. The definition of a module can either be determined by the imported TypeScript (.ts/.tsx) file, or by a type declaration file (.d.ts) that the code depends on. [Reference]

So, the solution is quite simple. We just have to tell TypeScript about our image files by adding a type declaration file (d.ts.), and declare the image files we’re using in our project as a module.

// images.d.ts

declare module '*.svg';
// duplicate for other image file extensions

Et voilà. Problem solved.

IoC in JavaScript with InversifyJS

In C#, interfaces are used to set up a definition that classes can implement. Any class that implements an interface must adhere to the definition declared by the interface.

Think of them as a sort of menu you’d find at a typical pizzeria. The menu says they serve Margherita pizza.

Then you have the classes that implement the interfaces - i.e. the cooks that prepare the pizza mentioned in the menu.

The pizzeria may have multiple cooks, and the cooks may differ in the way they prepare the dish - i.e. one cook may use more cheese, and another may use less salt in the dough. Regardless, the resulting product will still be served as Margherita pizza.

Similarly, the consumers of your modules should only be made aware of the “menu”, without having to worry about how the pizza is prepared. This way, you can swap out the “cook” whenever you want, without the consumers being any the wiser.

This is something I’ve been taking for granted in .NET development, and while there have been some efforts in bringing this concept to JavaScript, the implementation has not been that great - until now.