DEV Community: Dinos Vlachantonis

Typescript's excess property check limitations

Dinos Vlachantonis — Fri, 26 Feb 2021 08:21:41 +0000

The obvious

In Typescript, when we are trying to assign an object literal to a typed variable, it is reasonable to expect Typescript to check whether there are any extra properties that are not defined in the respective type.

interface Doggo {
  name: string;
  likesTreatos: boolean;
}

const max: Doggo = {
  name: 'Max',
  likesTreatos: true,
  age: 4
  /**
  Type '{ name: string; likesTreatos: true; age: number; }'
  is not assignable to type 'Doggo'.
  Object literal may only specify known properties, and 'age'
  does not exist in type 'Doggo'
  */
}

The not so obvious

Alright, let's tweak that piece of code a little bit and see how Typescript reacts.

interface Doggo {
  name: string;
  likesTreatos: boolean;
}

const dog = {
  name: 'Max',
  likesTreatos: true,
  age: 4
}

const max: Doggo = dog // no errors

Wait a second, the value of dog that we are trying to assign to our max is not so different than before, yet Typescript doesn't think that's an issue this time.

The triggers of the `excess property check`

Typescript does not complain because there is no excess property check triggered. The reason why is because it will only trigger on assignments that involve object literals, and dog is clearly not one.

On the first example above, our max variable was actually assigned to an object literal, triggering the check which then threw an error.

We can see a similar behavior when passing function parameters.

interface Doggo {
  name: string;
  likesTreatos: boolean;
}

function giveSnack(doggo: Doggo) {
  console.log(`Snack given to ${doggo.name}`)
}

giveSnack({
  name: 'Max',
  likesTreatos: true,
  age: 4
  /**
  Argument of type '{ name: string; likesTreatos: true; age: number; }'
  is not assignable to parameter of type 'Doggo'.
  Object literal may only specify known properties, and 'age'
  does not exist in type 'Doggo'
  */
})

const dog = {
  name: 'Max',
  likesTreatos: true,
  age: 4
}

giveSnack(dog) // no errors

But still, why would that not fail..?

It was hard for me to initially accept the fact that Typescript would allow an assignment like that.
But actually, as far as Typescript's structural type system is concerned, this is a totally valid scenario.

Let's take a step back.

interface Doggo {
  name: string;
  isGoodBoy?: boolean;
}

How big is the domain of values for the Doggo type?
The answer is, pretty huge!
Basically any object that has a name property that is a string and any other property besides a non-boolean isGoodBoy is a valid Doggo.

Based on that, here is a surprisingly valid assignment to a Doggo typed constant:

interface Doggo {
  name: string;
  isGoodBoy?: boolean;
}

const max: Doggo = window

window has a name property which is a string and does not have a non-boolean isGoodBoy property (even though it'd be cool).

Going back to our previous example

interface Doggo {
  name: string;
  likesTreatos: boolean;
}

const dog = {
  name: 'max',
  likesTreatos: true,
  age: 4
}

const max: Doggo = dog // no errors

This starts to make a bit more sense now, the variable dog is inferred as {name: string, likesTreatos: boolean, age: number} which is included in the domain of values of the type Doggo and hence being a valid assignment.
On top of that, the excess property check is not triggered because we are not dealing with object literals.

Final thoughts

One could say that Typescript's structural type checker focuses more on preventing us from writing code that would throw errors during runtime, while the excess property checking tries to identify code which might not be what we intended.

Breaking down confusion of combining Async/Await with Array.forEach()

Dinos Vlachantonis — Fri, 08 Nov 2019 11:38:11 +0000

Last week I was having a normal day at work when I suddenly stumbled upon something that really confused me. I was trying to loop an array and call an async function for each element. Yet, the result I was getting was not what I expected.

A dummy version of the situation I had could be:

const names = ['George', 'Margie', 'Anna']
const delay = () => new Promise(resolve => setTimeout(resolve, 3000))

names.forEach(async (name) => {
  await delay()
  console.log(`Greetings to you ${name}`)
})

console.log('farewell')

By simply running this in node we get the following result:

$ node awaitForEach.js

farewell
Greetings to you George
Greetings to you Margie
Greetings to you Anna

What? Wait a second...

That was not what I would expect to see. We definitely have an await when we are calling delay and Array.prototype.forEach is a synchronous function, so I would be quite confident that the greetings should appear before the farewell is printed in the console.

A deep look on `Array.prototype.forEach`

That can get quite very confusing, until you actually take a look at how Array.prototype.forEach is implemented.

A simplified version would be:

Array.prototype.forEach = function(callback, thisArg) {
  const array = this
  thisArg = thisArg || this
  for (let i = 0, l = array.length; i !== l; ++i) {
    callback.call(thisArg, array[i], i, array)
  }
}

As you can see, when we are calling the callback function, we are not waiting for it to finish.
That means, waiting for our delay() function to finish is not enough when Array.forEach() is not waiting for our callback to finish as well!

Let's try again

Alright, now we could solve this in many ways. But let's try to fixing the issue in the actual Array.forEach().

Let's write our own asyncForEach!

We just need to make the loop wait for the callback to finish before moving forward to the next element.

Array.prototype.asyncForEach = async function(callback, thisArg) {
  thisArg = thisArg || this
  for (let i = 0, l = this.length; i !== l; ++i) {
    await callback.call(thisArg, this[i], i, this)
  }
}

Then let's try our previous scenario. Now instead of Array.prototype.forEach we are going to use our own Array.prototype.asyncForEach.

(Note that we wrapped our code into a greetPeople() function, since we now need to await for the asyncForEach(), which can only be inside an async function.)

const greetPeople = async (names) => {
  const delay = () => new Promise(resolve => setTimeout(resolve, 3000))

  await names.asyncForEach(async (name) => {
    await delay()
    console.log(`Greetings to you ${name}`)
  })

  console.log('farewell')
}

greetPeople(['George', 'Margie', 'Anna'])

And as we all expect, if we now run our updated code the outcome is the one that we desire.

$ node awaitForEach.js

Greetings to you George
Greetings to you Margie
Greetings to you Anna
farewell

We made it!

We have our own async-friendly forEach array implementation.
Note that we could have the same behavior with other popular Array functions like Array.map or Array.filter.

Now I have to admit, this is probably not always going to be the best way to solve the issue.
But this is a great way understanding a bit better how Array.forEach actually works and in what scenarios it can get a bit problematic/confusing.

Meme award section

Well, if you are reading this it means that you actually read the whole thing, wow!
Your award is this nice corgi picture:

If you find any mistake do not hesitate to leave a comment.
Any feedback is welcome :)

End-to-end API testing using Knex & Migrations

Dinos Vlachantonis — Fri, 12 Apr 2019 07:46:54 +0000

When we are building an API it is usually a good idea to have some tests that cover the general flow, with as less mocking as possible.

Most of the times, your API will use/depend on one or multiple databases.
On one hand, it would be really nice if we could test our API without mocking anything database related, but on the other hand, we should avoid using our actual database for testing purposes, even if we actually clean up our mess afterwards.

Database Migrations to the rescue

It turns that database migrations can be really handy in this situation. It would be ideal if we could just before the tests, create a new database, migrate it, seed it (if needed) and then after the tests rollback and delete the database, like nothing ever happened.

Knex

In a node application, we can achieve something like that using Knex. All we would need to do is create a new testing database using Knex and then just apply the same migration setup that we have already implemented for our existing non-testing database.

How would this look like

Your already existing migration file. This is the migration that you are already using for your database. This is also the migration that we will be using to prepare the temporary test-database for our tests.
Note that you can also have a seeding file, so you can directly seed your tables with data, if needed.

import * as Knex from 'knex';

export async function up(knex: Knex): Promise<any> {
  return () =>
    knex.schema.createTable('table1', (t) => {
      t.increments('id')
        .primary()
        .notNullable()
        .unique('table1');
      // more columns
    });
    // more tables
}

export async function down(knex: Knex): Promise<any> {
  return () => knex.schema.dropTable('table1');
}

Your tests. Notice that in the beginning and in the end of every test suite, we are migrating and rollbacking respectively, so every test suite can have a fresh test-database.

const config = {
  client: 'postgres',
  debug: true,
  connection: {
    host: 'localhost',
    database: 'test_database',
    port: '5432',
    password: '',
    user: ''            
  },
  migrations: {
    directory: './migrations'
  },
  seeds: {
    directory: './seeds'
  }
};
const knex = require('knex')(config);

describe('test suite description', () => {
  beforeAll(() => {
    return knex.migrate.latest();
    // you can here also seed your tables, if you have any seeding files
  });
  afterAll(() => {
    return knex.migrate
      .rollback()
      .then(() => knex.destroy());
  });

  test('test 1', () => {
    // testing stuff
  });
  test('test 2', () => {
    // testing other stuff
  });
});

Last, we will be using the options globalSetup and globalTeardown options of Jest so we can create our database and also delete it before and after every Jest call respectively.

for the globalSetup:

import * as knex from 'knex';

function getDbConnection() {
  return knex({
    client: 'postgres',
    debug: true,
    connection: {
      host: "localhost"
      database: "postgres",
      port: "5432",
      password: "",
      user: "",            
    }
  });
}

async function createDatabase() {
  const dbConnection = getDbConnection();

  try {
    await dbConnection.raw('CREATE DATABASE test_database');
  } catch (err) {
    console.log(err);
  } finally {
    await dbConnection.destroy();
  }
}

module.exports = async () => {
  await createDatabase();
};

for the globalTeardown:

import * as knex from 'knex';

async function deleteDatabase() {
  const dbConnection = knex({
    client: 'postgres',
    debug: true,
    connection: {
      host: "localhost"
      database: "postgres",
      port: "5432",
      password: "",
      user: "",            
    }
  });

  try {
    await dbConnection.raw('DROP DATABASE IF EXISTS test_database');
  } catch (err) {
    console.log(err);
  } finally {
    await dbConnection.destroy();
  }
}

module.exports = async () => {
  await deleteDatabase();
};

Now we can run Jest and know that we will have a temporary test-database with the same schema as our original database.

Summary

We can use Knex in order to have a temporary database with which we can test the flow and the endpoints of our API without having to mock anything related to the database. We can be sure that the database tables' schema will be identical with the original, since we are going to use the same migration files that the normal database was built with.

PS: This is the first time I write anything, so I would really appreciate feedback and constructive criticism as well.