Monthly Archives: July 2019

Extension methods in TypeScript

Extension methods in C# are a great way to modularise functionality within a class in such a way (for example) to have a basic object with minimal methods and then extend this with further functionality that can be reference only if required.

Hence you might only have a need for the bare bones class in some cases and therefore only need to include that in your code base, alternatively you might also depend upon some advanced functionality that can be added when required. Another use case is adding functionality to third party libraries to extend their functionality.

Ofcourse we might simple extend/inherit from the class to add our new functionality but this ultimately mean’s we’re using a different type. With extension methods in C# we extend a String (for example) with extra functionality as opposed to created a subclass named something else, like ExtendedString.

So can we implement something similar to C#’s extension methods in TypeScript (and therefore JavaScript)? Yes we can, let’s look at a simple example, an Option class for handling defined/undefined values in a functional way. Here’s the Option.ts file

export class Option {
    value: any;

    constructor(value: any) {
        this.value = value;
    }

    isSome(): boolean {
        return this.value != null;  
    } 

    isNone(): boolean {
        return !this.isSome();
    }
}

Hence this is a bare bones implementation which we might extend further with further functionality. Let’s create a file for our extension methods, mine’s named OptionExtensions.ts, which might look something like this

import { Option } from './Option';

declare module './Option' {
    interface Option {
        ifElse(elseValue: any): any;
    }
}

Option.prototype.ifElse = function(elseValue: any): any {
    return this.isSome() ? this.value : elseValue;
}

In the above code we declare a module with the same name as the one which wish to extend and then declare an interface with our new methods. The interface in essences merges with the type to allow us to view our new methods as if they’re on the original Option type.

Finally we can start implementing our new functionality via the JavaScript prototype functionality.

In this example you can see we also have access to the this reference to allow our new functionality to hook into the Option fields etc.

Now let’s look at this in usage

import { Option } from "./Option"
import "./OptionExtensions";

const o = new Option(undefined);
console.log(o.ifElse(999));

That’s it, we pull in the extension methods via the import “./OptionExtensions”; when we want the extended functionality and we can call our extension methods as if they were written into the Option class itself.

Property based testing in JavaScript with fast-check

Property testing is a way to test functionality by automatically generating many different inputs.

We’re going to use the fast-check library

yarn add fast-check -D

Let’s create a rather contrived example function to test

export const divide = (a: number, b: number): number => {
  if(b === 0) {
    throw new Error("Denominator cannot be 0");
  }
  return a / b;
}

As you can see, this function simply divides a by b but will fails in the denominator is 0. This was done on purpose to ensure that there is a failing test available for a specific input value (I did say it was contrived).

Now to test this we might implement the following test

import * as fc from 'fast-check';

test("Divide property test", () => {
   fc.assert(
      fc.property(fc.nat(), fc.nat(), (a, b) => {
         return divide(a, b) === a / b; 
      })
  );
});

In this instance we create the assert which wraps the property generation code, i.e. the call to property, which itself generates two natural numbers properties as input to the lambda/fat arrow function.

We then call the code that we wish to test, passing in the generated values and then returning whether the expectation was true or false.

We can use Jest or the likes in place of the return divide(a, b) === a / b, i.e.
replacing it with if we prefer and just use fast-check to generate the properties

expect(divide(a, b)).toEqual(a / b);

Now the only problem with the property based testing like this is that it will randomly generate values as opposed to inspecting the flow of your code to generate values (like tools such as Pex for .NET). Hence these values may not always include the edge cases that we might not have coded for.

For example, executing this test in Jest I find that sometimes it will pass a 0 as a denominator and other times it will not, therefore we do not always get a clear idea of all possible inputs, but it’s a great starting point for proving your functions.

In the test we generated natural numbers, we can also generate restricted ranges of values, along with integers, floating point, doubles, strings and more, see Arbitraries.

Loading JavaScript objects from a string

As mentioned in a previous post – I’ve been working on dynamically loading TypeScript/JavaScript as required (i.e. like a runtime plugin system) and whilst investigating the process have come across several libraries that I felt I’d document in case I need them in the future. First up is require-from-string.

I’ll assume for this and any follow up posts, that you’ve created a basic set-up, i.e.

yarn init –typescript
tsc –init

Although I’ve added TypeScript in the above, for simplicity we’re going to start out just using JavaScript, but we’ve covered all bases with TypeScript’s inclusion.

Next create an index.js that looks like this

import requireFromString from 'require-from-string';

const classA = requireFromString('class A { output() { console.log("Remote class called") } } module.exports = A;');
new classA().output();

Adding webpack-dev-server

In previous posts we’ve used serve as our server, an alternative is the webpack-dev-server. This will give up live reloading and also built-in compilation so that we don’t need to run the build script.

Simply add the relevant package using

yarn add webpack-dev-server -D

Now add the following to your webpack.config.js, first the requires

const path = require('path');

and now the code for the server

module.exports = {
  // ... other config
  devServer: {
    contentBase: path.join(__dirname, 'dist'),
    compress: true,
    port: 5000

By default “Live reloading” is enabled and hence, now when we make changes to our code and save them, the browser automatically relaods.

We can now just change our “start” script within package.json to

"start": "webpack-dev-server --config config/webpack.config.js"

Modules and webpack

One of the things I wanted to do is allow my React application to “dynamically” load code from another website for an internal application. The idea being other teams can work on their code and the main application will load the latest deployed version if the user navigates to something that uses it – basically we’re talking about writing plugins.

Note: This is not a great idea for any code you cannot 100% control as you’ll obviously have no idea whether it’s malicious, so if you’re thinking of doing something similar make sure you know what code is being downloaded etc.

Where’s my Module gone

To begin with I wrote an “importer” class in a separate application which successfully loaded code – using axios to download it, Typescript to transpile it (if needed) and the standard Module to compile (module._compile) it, then I slotted the code into a Module and away you go. All worked great until it got deployed within the React application and all of a sudden _compile (and other methods) were missing from Module.

The thing is, webpack basically uses it’s own module system.

webpack modules

The post I wrote on getting up and running with webpack was inspired by the module dilemma as I needed to better understand what webpack was doing under the hood.

If we create and build a webpack project we’ll end up with main.js, here’s a snippet from it for the __webpack_require__ function

function __webpack_require__(moduleId) {
   if(installedModules[moduleId]) {
      return installedModules[moduleId].exports;
   }

   var module = installedModules[moduleId] = {
      i: moduleId,
      l: false,
      exports: {}
   };

   modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
   module.l = true;
   return module.exports;
}

Note: I’ve removed all the comments just to reduce it to the minimal code.

So within the functions web pack generates for our code/exports etc. we’ll see __webpack_require__ used a fair bit, i.e. to load import/require code (import/require is replaced with __webpack_require__) and looking at the function itself we can see that __webpack_require__ uses it’s own module system, i.e. it caches modules in installedModules (which becomes __webpack_require__.c). We can also see that if the module is not cached a new one is created which looks very different from a NodeModule.

Finally, after the module is created a call is made to the new module, which in this case is one of the functions that’s passed to the __webpack_require__ within main.js which basically returns a function to our code which then becomes the “exports” code returned by the __webpack_require__ function.

Up and running with webpack

Don’t read this blog post if you want to learn about webpack, instead go and read the webpack book.

If you’re still reading this post then let’s go ahead and create a minimal project to start learning about webpack.

Creating our project

Create a folder for our starter app., mine’s webpack-starter
Within the folder run
```
yarn init -y
```
to create our package.json
Now install/add webpack and webpack client using
```
yarn add webpack webpack-cli
```
Create a src folder off of you project’s root – webpack, by default expects a src folder
Add a file index.js to the src folder and we’ll include the minimal code, below
```
console.log("Hello World");
```

To your package.json file add the following

"scripts": {
   "build": "webpack --mode development"
}

At this point let’s take a look at what we’ve done. We’ve created a minimal package.json and to this added webpack and the webpack-cli. We’ve created a bare bones entry point (index.js) and a build script.

Now if we run the build script using

yarn build

webpack will generate a dist folder off our root folder along with a main.js file, one look at this and you’ll see far more than you probably expected. Webpack’s created a bootstrap along with a lot of module related code. At the bottom of the file is a function that simply executes the eval function which basically evaluates/runs the code that was in the index.js.

Testing our application

I know it’s a rather minimal application, but it’d be nice to see it actually working, so let’s add the relevant piece to the jigsaw

Run the following

yarn add html-webpack-plugin

We’re going to need to tell webpack to use this plugin, so create a new folder off of the root named config within this create a file name webpack.config.js and here’s the contents for this

const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  plugins: [
    new HtmlWebpackPlugin({
      title: "Webpack starter",
    }),
  ],
};

If you don’t have serve installed then add it using either the command below or add it globally (see React and serve).

yarn add server

Next up we’ll need to rebuild our dist source but before we do that, we placed the webpack.config.js into the config folder, running the build script as it stands will not pickup this file so you can either move it to the root folder or better still update the script to look like this

"scripts": {
   "build": "webpack --mode development --config config/webpack.config.js"
}

Now running yarn build will create, both an index.html file and main.js file within the dist folder. So now we can run the server. Before we do that, let’s add another script task to package.json, so add the following

"start": "serve dist"

Now we can run yarn start which will start a server up (by default it will be http://localhost:5000). Obviously we’re outputting text to the console so you’ll need to switch your browser to dev mode and view the console output.

Webpack output

When you ran yarn build, webpack used the configuration and the HTML plugin within it to generate our index.html file and also supply the title “Webpack starter”. The output from running webpack looked like this (for me at least)

Hash: af14b7dabddfbc78edb6
Version: webpack 4.35.2
Time: 507ms
Built at: 07/02/2019 10:43:49 AM
     Asset       Size  Chunks             Chunk Names
index.html  181 bytes          [emitted]
   main.js    3.8 KiB    main  [emitted]  main
Entrypoint main = main.js
[./src/index.js] 27 bytes {main} [built]
Child html-webpack-plugin for "index.html":
     1 asset
    Entrypoint undefined = index.html
    [./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 472 bytes {0} [built]
    [./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 497 bytes {0} [built]
        + 2 hidden modules
Done in 3.17s.

As you can see the Child html-webpack-plugin for “index.html”: text tells us what code was generated by the HtmlWebpackPlugin

Along with the creation of the index.html file HtmlWebpackPlugin setup a script tag for calling the webpack generated main.js file.

Before we move on let’s change our index.js file to include an import. So create the folder components off of the src folder and create the file helloComponent.js (code for this is shown below)

export default (text) => {
    const element = document.createElement("div");
    element.innerHTML = text;
    return element;
}

and change the index.js code to the following

import hello from "./components/helloComponent";

document.body.appendChild(hello("Hello World"));

Note: again the above is fundamentally the same as the webpack book. The main difference is that I’m wanting to make this look similar to how I’ve learned to use/set-up React as it helps give a feel for how one might transition between React and lower level webpack designed projects or vice versa.

Now run yarn build followed by yarn start. If all goes well you’ll see some interesting changes to the main.js file and ofcourse you should now see actual HTML elements in your browser. I’m far more interested in the main.js changes than the fact we have any output.

More on main.js

If you compare the original main.js file with the new one, you’ll notice that it’s fundamentally the same, it has the webpackBootstrap section as well as all the code setting up the __webpack_require__ properties. Ultimately though the original main.js came down to this line

(function(module, exports) {
eval("console.log(\"Hello World\");\n\n//# sourceURL=webpack:///./src/index.js?");
})

and we can clean this up further just turning it into

(function(module, exports) {
eval("console.log(\"Hello World\");");
})

With regards to the second implementation, although the bulk of the file is still made up with the webpackBootstrap code etc. now we have the following code combined into the single main.js file (I’ve removed comment blocks etc. to clean the code up somewhat)

(function(module, __webpack_exports__, __webpack_require__) {
"use strict";
eval("__webpack_require__.r(__webpack_exports__);\n/* harmony default export */ __webpack_exports__[\"default\"] = 
((text) => {\r\n    const element = document.createElement(\"div\");\r\n    element.innerHTML = text;\r\n    return 
element;\r\n});\n\n//# sourceURL=webpack:///./src/components/helloComponent.js?");
}),

/*! no exports provided */
(function(module, __webpack_exports__, __webpack_require__) {
"use strict";
eval("__webpack_require__.r(__webpack_exports__);\n/* harmony import */ var 
_components_helloComponent__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(/*! ./components/helloComponent */ \"./src/components/helloComponent.js\");\n\r\n\r\ndocument.body.appendChild(Object(_components_helloComponent__WEBPACK_IMPORTED_MODULE_0__[\"default\"])(\"Hello World\"));\n\n//# sourceURL=webpack:///./src/index.js?");
})

The first function is our helloComponent.js file wrapped in a function, notice how we no longer simply eval the JavaScript but instead eval __webpack_require__. The second function is our index.js.

There’s a lot going on, especially with all the commented code and new lines etc. so let’s clean it up, remove the eval function and format it and then we see that this is the index.js code in a function

__webpack_require__.r(__webpack_exports__);
var _components_helloComponent__WEBPACK_IMPORTED_MODULE_0__ = __webpack_require__(\"./src/components/helloComponent.js\");
document.body.appendChild(Object(_components_helloComponent__WEBPACK_IMPORTED_MODULE_0__[\"default\"])(\"Hello World\"));

The function that this code is within is passed a module, __webpack_exports__ and __webpack_require__, so firstly we call the function __webpack_require__.r with the __webpack_exports__ and this defines the property for either Module or __esModule.

Next we declare a variable named after the folder and filename (i.e. components/helloComponent changes to _components_helloComponent) which in turn is suffixed with the __WEBPACK_IMPORTED_MODULE_0__ (the number 0 increments for each addition module included). This variable is assigned the resultant module after passing the string “./src/components/helloComponent.js” to __webpack_require__. The string is simply a module id, hence as it’s based upon the file system will be unique to the project containing it.

The final line is a call to the document.body.appendChild (as per our index.js) but the function hello (exported from helloComponent) has been replaced by the _components_helloComponent__WEBPACK_IMPORTED_MODULE_0__ variable indexed by the default export.

Basically what’s happened is webpack has parsed our code, replacing the imports with functions which wrap the code from the imports. It’s created it’s own module system using __webpack_require__

What on earth are all the __webpack_require__ properties doing?

What’s happening is that the first function function(modules) (the webpackBootstrap function) is called, next the __webpack_require__ object is setup, with modules and installed modules being assigned to __webpack_require__.m, em>__webpack_require__.c and the rest of the properties setup with functions and so on.

Here’s a list of the current _webpack_require__ properties and their usage (taken from the webpack source)

__webpack_require__.s = the module id of the entry point
__webpack_require__.c = the module cache
__webpack_require__.m = the module functions
__webpack_require__.p = the bundle public path
__webpack_require__.i = the identity function used for harmony imports
__webpack_require__.e = the chunk ensure function
__webpack_require__.d = the exported property define getter function
__webpack_require__.o = Object.prototype.hasOwnProperty.call
__webpack_require__.r = define compatibility on export
__webpack_require__.t = create a fake namespace object
__webpack_require__.n = compatibility get default export
__webpack_require__.h = the webpack hash
__webpack_require__.w = an object containing all installed WebAssembly.Instance export objects keyed by module id
__webpack_require__.oe = the uncaught error handler for the webpack runtime
__webpack_require__.nc = the script nonce

Webpack Loaders

I’m going to end this post with a very quick look at webpack loaders. Whilst there’s nothing wrong with using plain JavaScript, I come from a statically typed world and rather like using TypeScript to catch those stupid mistakes. So let’s set-up webpack to work with TypeScript.

Webpack comes with the concept of loaders, these are basically file processors that become part of the webpack pipeline. For example, they might generate code from configuration files or transpile from other languages etc. Everything then gets bundled via the webpack pipeline.

To add typescript capabilities to webpack we need to edit the webpack.config.js, adding the following

module: {
   rules: [
      {
         test: /\.tsx?$/,
         use: 'ts-loader',
         exclude: /node_modules/
      }
    ]
  },
  resolve: {
    extensions: [ '.tsx', '.ts', '.js' ]
  }

We’ll also need to run

yarn add typescript ts-loader

To installed typescript (if not already installed) and ts-loader, which is used within webpack. Assuming you’re going to now change all .js files (including index.js) to .ts files you’ll also need to amend the webpack.config.js entry to this

entry: './src/index.ts',

Now run your build script as normal and assuming your code is valid TypeScript then you should successfully created a webpack bundle based upon your TypeScript code.

I think that about covers getting webpack up and running, but I’m sure there’ll be more posts on the topic as I delve deeper.

My Memory

Outsourcing my memory and thoughts (and other ramblings) to the web