Extending TypeScript to serialise Map objects to JSON

The collection objects offered by ES6 such as Map and Set are indeed a marvel. One notable downside to them though is that they don’t serialise to JSON. For example

Results in

Always – irrespective of what is in the map collection. Not great and a pain when we want to stash the map object in a cookie or local storage to be used later. It just doesn’t do it out of the box. Here I’m going to extend TypeScript to do this so I will never need to think about it again.

Serialising the Map object.

There are a number of different ways to get the Map object to serialise and deserialise in and out of JSON. This one relies on the contents of the Map object being serialisable. If they are then we can do the following

Serialise Map into JSON

Deserialise JSON into Map

This works in JavaScript (ES6) and TypeScript – which after all is a superset of JavaScript.

Serialise the Map Object

It feels a bit clunky to have these methods hanging around in some utility library. What I want to do is extend the TypeScript Map class to have these. To do this go to a TypeScript definition file (*.d.ts) and enter the following

This will extend our map object to have a toJson method. In a suitable library file place the implementation and associate with the prototype object of the Map object

It’s not hugely intuitive why we need to extend the prototype object at this point. From the mozilla documention

All Map instances inherit from Map.prototype.

So if we want our new method on an instance of the Map object we need to extend the prototype object –  because Map instances all inherit from this.

This is then called thus

Which can then be stashed away in local storage or the like.

Deserialise a JSON string into a Map object

We are going to do similar to implement the deserialisation part. It’s not quite the same though. If we are serialising a Map object it makes sense to have the toJson method associated with an instance of a Map object. If we are deserialising into a new Map object we want the method associated with the class- like a static method in C#. The following illustrates the difference

Again go to a TypeScript definition file (*.d.ts) and enter the following

Note – this time I am extending the MapConstructor object rather than the Map<K,V> object. In TypeScript the MapConstructor object returns a reference to the Map function that created the object. So by extending the MapConstructor Typescript object I am associating the method with the object that created the instance of the map object. I am associating the new method with the class and not the instance.

Now associate our implementation directly with the Map object which itself implements MapConstructor

Which we call thus

That’s it – the Map object now has toJson and fromJson methods which handle our JSON conversion. The Set object suffers from the same limitations and can be extended in the same way.

Useful Links

Map and Set objects are part of the ES6 standard. TypeScript offers a strongly typed version of these collections

More detail about extending built in types in TypeScript

The initial code to serialise and deserialise the Map object came from a stack overflow question i.e.

but I’ve forgotten which one – if I find it I will pop the reference here in the interest of full disclosure and not ripping off someone else’s work and claiming it for my own.

Not as irreplaceable as I thought

Like all software developers, I like to think of myself as being irreplaceable. Clearly no-one on the entire planet combines my depth of technical knowledge, my amazing familiarly with the business domain and my legendary humility. I am truly a unique gift to any and all employers.

So I was particularly disappointed this week when I was replaced my this play-mobile figure at the family dinner table . I was out that evening so the daughter placed this unkempt looking plastic figure in my chair . She felt it was an adequate or even superior replacement. It’s uncertain whether my wife noticed the difference. Certainly the level of conversation was improved that evening.

So not as irreplaceable as I thought. I once replaced a colleague with a blow up sheep and sent him the photo. I thought it was very funny at the time – I realise now that it wasn’t as funny as I thought. I really hope my employer doesn’t realise how easily I can be replaced by a cheap child’s toy.

Selecting from a column with possible NULLs in T-SQL

I write blog posts for different reasons. Sometimes it’s because things aren’t well documented elsewhere, sometimes it’s new and interesting and sometimes it’s purely for my own amusement. Occasionally I write things as I kind of penance – things I should know about but bizarrely forgot or misunderstood. This is one of those. It’s how to select from a column with possible NULLs and not omit expected rows from the results set. This has been documented at length elsewhere but that’s not the point of penance.

Test Cases – equals operator

Working through some examples when comparing NULLs with the equals operator.

NULL is equal to ‘test’

False: as expected

NULL is not equal ‘test’

False:  less expected

NULL is not equal to NULL

False: more expected

NULL is equal to NULL

False: odd again

NULL isn’t equal to anything including itself when using the equals operator. I know this really and we see the same kind of thing in JavaScript.

Test cases – IS NULL

Of course it well known that equals doesn’t do the job with NULLS. The IS NULL operator is correct

Null is null


Null is not null


All as expected.

Test case -selecting from a column with possible NULLs

So this is what tripped me up – when you have a column that is nullable and trying to filter as a string.

I naively thought that there are 2 rows that aren’t ‘Test’ so we will get those. But since NULL is not equal to ‘Test’ and not not equal to ‘Test’ then actually we get one less row than we expected

The correct select is

Which converts the NULL to an empty string so then works

Also works and is the same. Penitential blog post over.

Useful Links

Comparison of ISNULL and COALESCE

It’s not just T-SQL. Special handling around NULLs in JavaScript

SQL Server restore fails if backups taken in rapid succession

How I (unfairly) think of SQL Server

I don’t spend an awful lot of time thinking about SQL Server. To me it’s a workhorse which I think is a compliment. * It’s steady, reliable and gets the job done. It’s not glamorous though and people don’t talk about it at dinner parties.

I did have cause to give the old SQL Server workhorse a bit more thought recently. I’m having to do a bit of database work and I’m taking lots of backups in rapid succession and restoring them. For some reason the backups didn’t restore the most recent version of the database. The restored DB was weirdly out of date. I got round this by going to options on the backup dialog and selecting ‘Overwrite existing backup sets’

Once I’d blatted out the existing sets then it worked fine. I don’t know why it wouldn’t work if I appended to backup sets and clearly this is a development environment workaround. I’m not advocating people merrily wiping out backup sets on production sets. A better workaround might have been to start using snapshots but once the workhorse was lashed back to the plough then I was happy. That said, I’d be very interested to know why it was doing that if anyone knows.

* On reflection, I wouldn’t like it if called me a workhorse so perhaps it’s not as much of a compliment as I imagine.

LINQ FirstOrDefault implementation in TypeScript

Proust looking of of the window thinking about LINQ operators

Confession: when working in JavaScript languages I kind of miss some C# things such as LINQ. A substantial part of my C# coding seemed to be chaining LINQ operators together. So rather than staring wistfully out of the window  in remembrance of things past – I thought I would just try to write one of my own. I’ve picked FirstOrDefault for this honour.


For the uninitiated FirstOrDefault is a LINQ operator in C# that takes a function which resolves to a boolean – a predicate. It has the following characteristics

  1. Returns the first object in a collection that matches the predicate
  2. If it can’t find one then it will return null
  3. It won’t throw an exception if it can’t make the match – in contrast to it’s harsher sibling SingleOrDefault that will


I’m writing this In TypeScript – simply because that’s what I’m using at the moment. It would actually be easier to do this in plain JavaScript – the prototype will be the same and they would be no steps to hook it into the TypeScript interface. But we will do it in TypeScript


Step 1: Extending Array Type

In C#, the LINQ operators are an extension of IEnumerable<T>. In TypeScript we will extend the Array object which is a similar principle. In Typescript type definitions go in .d.ts files. I’m working in Angular and there is handily a definition file already present – typings.d.ts. In that file put the following

This adds a firstOrDefault defintion to the Array type. It takes a function just like the C# first or default method. As we are using TypeScript we can specify a type of function for the parameter so we will get compile errors if we try to supply anything else to this method. Of course there is no implementation yet ….

Step 2: Implementing the LINQ operator

Create a file e.g. Linq.ts and enter the following

This method is going to do the work – it’s the meat and potatoes. We are leveraging the reduce operator. Reduce flattens a collection into a single value – a simple example would be totalling all the numeric values in an array i.e.

For us flattening the array means returning the first value that matches the predicate. So we iterate through until predicate(currentValue) evaluates to true then we stash the value in the accumulator object and once there we never write over it.

An interesting quirk to this is what happens on the first loop – if we call it like this

i.e. reduce with a single argument. In the first iteration the accumulator has the value of the first object in the array; the currentValue has the second. The first item is already stashed in the accumulator and the predicate is never checked – the first item is always returned no matter what the filter is. This is exactly what we don’t want. We need to supply a second argument to reduce …..

By supplying a second argument we specify what the initial value of the accumulator is. We want a initial value of null so our LINQ operator will attempt the match each time until it succeeds.

As a side note – I’m aware that there are any number of ways to achieve this but I’ve a theory that all of the LINQ operators can be done with JavaScript reduce, map or filter methods so this is my first step to prove that theory out. It can be done and it will be done (if I get the time).

Step 3. Consuming the LINQ operator

Import the linq prototype and use thus

This returns the first object in the array with an Id of 1. This compares quite nicely with the C# FirstOrDefault method which is

Which looks pretty similar to me and works in the same way. It doesn’t do a great job with type checking though and since we are using TypeScript we can do a bit better.

Implementation with Generics

We can use generics in TypeScript to get type checking in the predicate and get a typed returned value. An improvement I think.

Step 1: Extending Array Type

Go to the d.ts file again and use this

Which defines a function that takes type T and returns a boolean – our filtering predicate.

And a generic array extension which uses the typed predicate instead of the more generic Function type.

Step 2: Implementing the LINQ operator

Change the implementation to this

Which uses the generic types throughout.

Step 3. Consuming the LINQ operator

If we were using a collection of persons, the new generic powered firstOrDefault would be called like this

We can now get decent intellisense when filling in the filter conditions and type checking so we don’t compare the wrong types. It’s slightly more verbose than the first example but safer to use. I prefer it, but use whichever floats your TypeScript boat – both work.

Useful Links

More detail about extending built in types in TypeScript

Nice comparison of the map, filter and reduce methods in JavaScript and guidance about which to use when.

Overview of LINQ operators. There’s more than you think.

When I’m talking about LINQ I’m really talking about LINQ to objects. There is LINQ to SQL, LINQ to entities, LINQ to XML etc.. This SO question points out the difference.

There are two styles of operators in LINQ – lambda and query syntax. Query syntax is

And the equivalent lamdba is

I’m emulating the lamdba syntax here. I never use the query syntax – I think it was easy route to LINQ for people more familiar with SQL. The lamdba is a more functional approach and nearer to what the code is actually doing. Anyway the query operator was only ever a sub set of the lamdba.

Copying static files into build directory with Angular

This is probably obvious for Angular aficionados and aficionadistas but I found how to copy static files into the output directory of an angular application non-obvious.

To do it go to angular-cli.json in your project root and add the static file to the assets collection thus

And it places it nicely into the output folder which is dist by default. I found this useful when using a web.config file to set up some URL rewriting rules in an IIS hosting scenario i.e..

Just though I would break it out of that post and flag up how to do it when I had a spare 10 mins between cleaning the bathroom and taking the daughter to swimming lessons (too much information – sorry).