DEV Community: jmc265

Typescript File Inheritance

jmc265 — Mon, 07 Sep 2020 19:45:42 +0000

I am not sure how useful this pattern is, but it has some interesting effects, especially when sharing code between projects. So let me give you a brief description of it and you can see where to apply it.

Imagine we are writing a simple Web App with a frontend, written in Typescript, and a Node backend, also written in Typescript. This is an excellent opportunity to share some code between the 2 projects. Let's say this simple webapp has a User entity that is passed back and forth between the frontend and the backend, and that the backend stores the User in a database. The database entry might have some additional properties, like password which we don't want to share with the frontend.

First, we are going to create a shared representation of a RequestUser. This interface will be used by both the front-end and the backend and it in a top-level folder called shared:

shared/user.ts

interface RequestUser {
    name: string;
    email: string;
}

Then, in the api folder, we want to use the RequestUser interface, but add to it to store more items in the Database entry:

api/user.ts

import * as User from "../shared/user.ts";

interface DatabaseUser extends RequestUser {
    password: string;
}

This all seems fine, but what happens when we want to use both RequestUser and DatabaseUser interfaces in our API handler, keeping in mind the import * as ... patten previously described?

api/handler.ts

import * as User from "../shared/user.ts";
import * as ApiUser from "./user.ts";

export function handler(body: any) {
    const rqUser: User.RequestUser = body.user as User.RequestUser;
    const dbUser: ApiUser.DatabaseUser = {
        ...rqUser,
        "password": 'P@55word'
    }
}

We now have 2 name spaces, ApiUser and User to represent User type models. We can compress that down to 1 namespace, using the export * from pattern. If we look again at our API-specific model file, we can tell it to export everything from the shared model, essentially inheriting all the exported members from that file:

api/user.ts

import * as User from "../shared/user.ts";
export * from "../shared/user.ts";
...

And then in our handler again, we can clear up some of the references:

api/handler.ts

import * as User from "./user.ts";

export function handler(body: any) {
    const rqUser: User.RequestUser = body.user as User.RequestUser;
    const dbUser: User.DatabaseUser = {
        ...rqUser,
        "password": 'P@55word'
    }
}

We have one less import, and we can see that the RequestUser and DatabaseUser are very closely related as they both come from the same namespace. It is slightly cleaner code, and lets newcomers to our code read and scan it with ease.

Using BitWarden and Chezmoi to manage SSH keys

jmc265 — Fri, 28 Aug 2020 19:14:42 +0000

I have recently started using Chezmoi to manage my dotfiles (and various other pieces software config) across multiple machines. The distribution is done via a git repo and therefore we should not check in secrets such as the private part of the SSH key. Using Bitwarden, we can store the key in a Secure Note and retrieve on the other machines.

Setup

The rest of this post assumes you already have Chezmoi installed and set up:

curl -sfL https://git.io/chezmoi | sh
chezmoi init

You will also need a pre-existing SSH key:

ssh_keygen -o

Store the key

The public key part of the SSH key can be stored in Chezmoi in plain text:

chezmoi add .ssh/id_rsa.pub

To store the private part we are going to need to install the bitwarden-cli and then login and unlock it:

bw login <EMAIL-ADDRESS>
bw unlock
export BW_SESSION="<SESSION-ID>"

Now, we get to the magic sauce. This line will store your SSH key (stored at ~/.ssh/id_rsa) in a secure note in Bitwarden:

echo "{\"organizationId\":null,\"folderId\":null,\"type\":2,\"name\":\"sshkey\",\"notes\":\"$(sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/\\\\n/g' ~/.ssh/id_rsa)\",\"favorite\":false,\"fields\":[],\"login\":null,\"secureNote\":{\"type\":0},\"card\":null,\"identity\":null}" | bw encode | bw create item

And finally, we need to tell chezmoi where to get the key from. Create a file in your chezmoi repo at this location: private_dot_ssh/private_id_rsa.tmpl and add this as the contents:

{{ (bitwarden "item" "sshkey").notes }}

(For OSX, this file needs a new line character at the end. For Linux, I believe it mustn't, so you might need to end the file with -}} instead)

Make sure all the files are committed and pushed to the origin.

Retrieve the key

On another machine where you want to retrieve the same key, make sure bitwarden-cli and Chezmoi are installed and first do the same login and unlock steps for Bitwarden as above. Then simplpy do:

chezmoi init --apply <GIT-REPO>

And that's it. Check your private key has made it safely to your machine by doing cat ~/.ssh/id_rsa.

You can see the full example of my chezmoi config here.

Typescript Multi Async Interface

jmc265 — Fri, 21 Aug 2020 18:58:15 +0000

I recently had to write a Javascript library which was going to be used in multiple different contexts by lots of different people. The purpose of the library was to supply a stream of updating values. Internally to the library, RxJS is used as it excellently models streams of updating values. However, the interface to the library should not expose the inner workings.

So, I wanted to allow the consumer of the library to access the values in a number of ways:

Usage

Promises

The standard way of supplying asynchronous values. It is commonly used and with async/await the code is very readable:

const currentValue = await lib.getValue();

The problem with this is, you can only get one value, you won't receive any further updates to the value. So, we can also support the next access method:

Event Emitter

This will allow the consumer to subscribe to updates in the value and the syntax would be as follows:

let currentValue;
lib.getValue()
   .onNew((value) => currentValue = value);

Synchronous

I also wanted to allow the users of the library to synchronously obtain the latest as well as all previous values when they were unable to use async or event emitters:

const currentValue = lib.getValue().latest();
const previousValues = lib.getValue().all();

Implementation

We can see above that the getValue() function has some interesting properties. It returns something which can be listened to like a promise, but it also returns an object which has other methods on it for accessing the values. So what does this object look like? Well here is a Typescript interface describing the object that getValue() returns:

interface AsyncAccessor<T> extends PromiseLike<T> {
    onNew(listener: (value: T) => void): void;
    latest(): T;
    all(): T[];
}

And using RxJS, the implementation of this class is fairly simple:

class ValueAccessor<T> implements AsyncAccessor<T> {
    private _previousValues: T[] = [];

    constructor(private _valueStream: Observable<T>) {
        _valueSteam.subscribe(v => this._previousValues.push(v));
    }

    public getLatest(): T {
        return this._previousValues[this._previousValues.length-1];
    }

    public getAll(): T[] {
        return this._previousValues;
    }

    public onNew(listener: (value: T) => void) {
        this._valueSteam.subscribe(value => listener(value));
    }

    public then<TResult1 = T, TResult2 = never>(onfulfilled?: (value: T) => TResult1 | PromiseLike<TResult1>, onrejected?: (reason: any) => TResult2 | PromiseLike<TResult2>): PromiseLike<TResult1 | TResult2> {
        const previousValue = this.getLatest();
        if (previousValue) {
            return Promise.resolve(previousValue)
                        .then(onfulfilled, onrejected);
        }
        return this._valueSteam
                    .pipe(first())
                    .toPromise()
                    .then(onfulfilled, onrejected);
    }
}

And that's it. We now have a value accessor that can be used in a number of different values by a consumer to the library.

Typescript `import * as ...`

jmc265 — Fri, 14 Aug 2020 20:22:21 +0000

There is a very easy to use and simple pattern that can be used whilst importing files in Typescript. The main advantage of using this pattern is to increase the readability and scan-ability of code. And that pattern is import * as ...

It is especially useful when it is used with models, so let's have a look at a very simple model:

user.ts

interface UserType {
    firstName: string;
    surname: string;
}

export function fromJson(input: any): UserType {
    return {
        firstName: input.firstName || "",
        surname: input.surname || ""
    }
}

export function getName(user: UserType): string {
    return `${user.firstName} ${user.surname}`;
}

If we don't use the import * syntax, we would have to import the 2 functions separately as follows:

import {fromJson, getName} from 'user.ts';

const input = { /* some JSON */ }}
const object = fromJson(input);
console.log(getName(object));

The above is not particularly easily to scan. We get to the usage of fromJson, but as the reader we have to break our scan by either looking at the top of file to see where the function came from or use our IDE's intellisense to see what the type of object is. Furthermore, on the next line, the function name getName might not remain unique to User.

So, in order to make the code easier to scan and parse for others, we can user the import * as pattern:

import * as User from 'user.ts';

const input = { /* some JSON */ }}
const object = User.fromJson(input);
console.log(User.getName(object));

From scanning this file, the reader can very quickly understand that the variable object is a User because the function fromJson is namespaced to that file. The getName call can now be disambiguated from a getName function that might exist on another type of object.

This pattern also works nicely for utils or helpers, as such:

const user = db.getUser();
const user = cache.getUser();
const user = queue.getUser();