Type inferences are powerful and allows us to do magic when we don’t know types.

const i: any = 1;
console.log(i);
// 1

unknown seems to do the same thing.

let x: unknown = 1;
console.log(x);

So, which to use where?

Let us extend the previous examples to put that question to rest. Consider what happens when you try to do any operation on the type.

const i: any = 1;
console.log(i + 1);
//2

const x: unknown = 1;
console.log(x + 1);
// error TS2365: Operator '+' cannot be applied to types 'unknown' and '1'

unknown applies itself enthusiastically to equality operations, asserts and checks, but not for any other operations.

This makes sense because we do not know the type of the particular variable and cannot subject it to operations or methods that expect a specific type.

Using unknown lends itself to better type safety and is recommended to be used for unknown data types.

We have seen interfaces used as types and interfaces as array types. Since function is an object and interfaces are supported on other objects, they should be supported on functions also. Right?

You betcha.

What is this blog if we can’t write about all the stuff that no one care’s about? Well, to be clear - I am not starting that trend today.

Let’s see an example of a simple function -

function getSum(x: number, y: number) {
  return x + y;
}

console.log(getSum(1, 2));
// 3

Imagine we have to support similar functions for all other million mathematical expressions. What are we going to do? Write a million types - never! We are no beasts.

We do something graceful using them interfaces and apply them to the function arguments.

interface twoNumOp {
  x: number;
  y: number;
}

function getSum(z: twoNumOp) {
  return z.x + z.y;
}

console.log(getSum({ x: 1, y: 2 }));
// 3

Quite neat - won’t you say? But, it can be much neater.

We will wrap the entire darn function with an interface so that it covers all the things required to support the million math operations.

interface twoNumOp {
  (x: number, y: number): void;
}

function getSum(x: number, y: number) {
  return x + y;
}

const summerOfAll: twoNumOp = getSum;
console.log(summerOfAll(1, 2));
// 3

The added advantage - you don’t go about changing function signatures for object oriented programming. That is so 2000s. Now, you just mask (interface) the non-OOP beauty.

Let’s say you have another function with a similar signature,

function getProd(x: number, y: number) {
  return x * y;
}

.. all you have to do is to apply signature..

const prodOfTwo: twoNumOp = getProd;
console.log(prodOfTwo(1, 2));
// 2

And, you are off to races (or wherever you go after you code a million math op’s).

No Javascript is an island. It was an island about two decades back but Javascript has done some pretty good land reclaimation to form large continents now.

So it goes without saying that these are not the days of writing Javascript or Typescript in <script> tag in a single HTML. A typical project has hundreds of packages and a lot of code written by you and others who hate you.

While it can be easy enough to split code in separate files to try maintaining them - they can get confusing and a bit dangerous since everyone has access to global scope.

Ergo, modules.

Modules provide a convenient way to split code and keep everything incl. scope tidy. Let’s see some examples on how we can create and use modules.

Export a function / variable

A module is typically written in its own file, and thereon affectionately called as “external module”.

An external module has what is called “top level export”. The export statement is at the file level and is not under a class or function.

An “internal module” is no more called that, but is called “namespaces”. We will deal with it at a later time.

Consider a simple example of an external module -

// math-op.ts

const double = 2;

function getSumDouble(x: number, y: number) {
  return (x + y) ** double;
}

export = {
  getSumDoub: getSumDouble
};

The code block is introduced in a separate file - it brings not only code clarity and readability due to lesser code, but also narrower scope.

The export statement tells the module what exactly is available to other files that import this module. We are just exporting a single function from the file, but we could export everything as well.

Let’s see how we can consume the module -

// Caller.ts
import MathOp = require("./math-op");

console.log(MathOp.getSumDoub(1, 2));
// 9

We just use a variable math, import the module to that variable and use the exported function. The usage is “normal” and does not introduce any complexities!

Let’s now try to access double, which is a variable in math-op.ts.

// Caller.ts

//  ...

console.log(MathOp.double);
// error TS2339: Property 'double' does not exist on type '{ getSumDoub: (x: number, y: number) => number; }'

Any variable or method which is not exported from the module stay local to that module.

We can export the variable also, if required.

// math-op.ts

//  ...

export = {
  getSumDoub: getSumDouble,
  double: double
};

Now, we can get the value from the external file.

// Caller.ts

console.log(MathOp.double);
// 2

Export a class

A more common pattern that you see in the real world is exporting classes.

The module is rewritten to contain and export a class. You can then use that class and access its members and variables.

// math-op.ts

export class MathThis {
  private double = 2;

  getSumDouble(x: number, y: number) {
    return (x + y) ** this.double;
  }
}

You can call and use this class like so -

// Caller.ts

import MathOp = require("./math-op");

const mathMatters = new MathOp.MathThis();
console.log(mathMatters.getSumDouble(1, 2));
// 9

We have seen interfaces used as types before. But as our God Goop says - “abstract; (while && when) you can;”. So, we are here to know about interfaces for interfaces.

Consider this simple example -

interface Borg {
  name: string;
}

Now, any class implementing the interface Borg will have a name attribute.

What if you want to add more attributes? Well, you can always add attributes to Borg, but what if you have a function that very much likes names and cannot digest anything else?

Or, you have security rules requiring you to obfuscate or hide stuff?

In all those cases and because we like to build incrementally and in a layered fashion, we should be looking at interfaces to interfaces.

For example -

interface Borg {
  name: string;
}

interface Borger {
  ssn: string;
}

Now, we could have an object implementing Borg or Borger.

const bo1: Borg = {
  name: "Queen"
};

const co1: Borger = { name: "Queen", ssn: "collective" };

Borger must have ssn from parent interface and name from the inherited interface.

Finis

The conversation at this point will be something like -

You: “Ok guy, I am excited. Let’s derive some interfaces”.

Me: “You crazy? Why do you think I give names like ‘Borg’ to the poor objects. Be careful about joining the collective.”

In reality: I don’t typically use interfaces on interfaces on interfaces. I am just not fixated enough on object oriented patterns even after two decades of working with them.

Previously we have seen interfaces as types. Interfaces provide useful abstraction on class and can be useful in tricky situations with complex types.

But, what about interfaces for array?

It turns out interfaces can be as easily applied for array types as well. They are just super useful as interfaces that define complex types and make arrays type-safe - nothing more, nothing less.

Interfaces can define type for both array and its values. Let’s see an example.

interface iPlanet {
  [index: number]: string;
}

const planets: iPlanet = ["earth", "mars", "mercury"];

console.log(planets);
// [ 'earth', 'mars', 'mercury' ]

Did I hear you say that you learnt this doing Javascript in kindergarten?

Well, yes - very much possible.

But, did you use a different type of index? How about layering the complexity with objects as values or for index?

interface iPlanet {
  [index: string]: iPlaPo;
}

interface iPlaPo {
  name: string;
  position: number;
}

let planets = new Array<iPlanet>();

planets["earth"] = { name: "earth", position: 3 };
planets["mars"] = { name: "mars", position: 4 };

console.log(planets);

/* output
[
  earth: { name: 'earth', position: 3 },
  mars: { name: 'mars', position: 4 }
]
*/

The example is not useful by itself. But you can quite imagine what it could be. Complicated data structures can be self-contained within arrays and subject to some sweet iterations.

Anonymous functions are just functions without names. If you have been following this blog, or have written some Javascript - you surely would have come across them.

Anonymous functions are just function expressions. Let’s see a quick example.

The following code block has a ’named’ function.

function getSum(x: number, y: number): number {
  return x + y;
}

We can rewrite the same as an anonymous function and get the same end result.

const getASum = function(x: number, y: number) {
  return x + y;
};

console.log(getASum(1, 2));
// 3

As it was in Javascript, the function declaration in anonymous functions get compiled only when the runtime engine gets to the particular statement. In other words, anonymous functions are not hoisted.

“Normal” functions get parsed at the compile time, regardless of whether they are used or unused.

Wot? But, this is similar arrow functions?

Yes, and no.

Arrow functions (or lambda functions) help us further the idea of Javascript - “every function is an object”. They allow us to pass around functions, and build incrementally complicated code that no one can understand.

Here’s an arrow function.

const getRSum = (x: number, y: number) => {
  return x + y;
};

console.log(getRSum(1, 2));
// 3

The only three differences -

• arrow functions can be named while anonymous functions wish to stay unnamed
• more importantly: anonymous functions have their own this context and arguments object while arrow functions inherit from parent/scope
• arrow functions cannot be called with new keyword

For all practical purposes I just use arrow functions and call it a day.

We have seen a bit of classes and objects in Typescript previously. There was however a key aspect of object oriented programming missing there. Although we discussed inheriting classes, we never mentioned abstract classes.

Sacrilege, that.

On the other hand, anything goes for the daily blogging gobble-gobble.

Abstract classes are meant to be inherited and are not used directly. Defining such an abstract class is painfully easy.

abstract class Planet {
  constructor(public name: string) {
    console.log("abstracted herein:", name);
  }
}

Using abstract classes is easy too..

const planet = new Planet("Pluto");
// error TS2511: Cannot create an instance of an abstract class.

Sorry, wrong code block there. Let me correct that.

class Earth extends Planet {
  constructor() {
    super("earth");
  }
}

const earth = new Earth();
console.log(earth.name);
// earth

Let’s go ahead and throw an abstract method there and see the fun unravel.

abstract class Planet {
  constructor(public name: string) {
    console.log("abstracted herein:", name);
  }

  abstract printLife = () => {
    console.log("everything", 42);
  };
}

class Earth extends Planet {
  constructor() {
    super("earth");
  }

  printLife: () => void;
}

const earth = new Earth();
console.log(earth.name);
console.log(earth.printLife());

/*  earth
    everything 42
    undefined // function doesn't return anything
*/

If you are wondering whatever the hell happened there -

• Create abstract class
• Introduce a silly abstract method to console.log something
• Extend Planet with a class aptly called Earth. Earth must implement the abstract method, else compilation fails
• Create an instance of the derived class, again aptly named as earth
• Make everyone reach nirvana by consoling some statements

enums have the following typical definition and usage -

enum Colors {
  red,
  blue,
  green
}

console.log(Colors[1]);
// blue

Or, the numbers can be explicitly specified..

enum Colors {
  red = 1,
  blue = 2,
  green = 3
}

console.log(Colors[1]);
// red

console.log(Colors["red"]);
// 1

Since Typescript v2.2, we can also specify non-numbers against the value.

enum FruitColors {
    apple = "red",
    orange = "orange",

}

console.log(FruitColors['apple']);
// red

Or, you could go crazy with more complex objects (but, why?).

enum Fruit {
  apple = <any>{ color: "red", flavor: "sweet" },
  orange = <any>{ color: "orange", flavor: "sweet" }
}

console.log(Fruit["apple"]);
// { color: 'red', flavor: 'sweet' }

Decorators are not available in Javascript but enable us to enhance our Typescript libraries and code. Decorators are experimental features in Typescript at this time.

A decorator is a way to annotate or modify a class, properties, functions or parameters. Decorator is specified against a target class, and has a body that indicates the decorator’s function.

A decorator exists in brought to life in two parts -

1. Define a function to apply against target class, property etc.

   function specialpower(meta: any) {
     // do something
   }
   

2. Then, the decorator is specified against the class, member, etc.

   @specialpower
   class Human {
     // ..
   }
   

More than one decorator can be applied in one go.

@eat
@repeat
class Human {
  // ..
}

The functions are evaluated left to right, and then, top to bottom, as applicable. The results are then called from the last evaluation from previous step to the first.

As an example, consider the below decorator to add a new property to the class.

function propPower(constr: any) {
  return class extends constr {
    power = "life";
  };
}

Next, we specify the decorator against the class.

@propPower
class Planet {
  constructor() {}
}

We can see the power added to the class without any further action from our end -

const earth = new Planet();
console.log(earth);
// class_1 { power: 'life' }

You can see the potential here - we can start adding “stuff” to props, members and classes, and take Typescript to all new levels. But remember - they are experimental and can change.

If you cannot wait to see decorators today - you can always use NestJS or Angular frameworks. They have decorator support built in and people seem to go crazy about them (I am neutral).

We see a lot about “type assertions” in to type conversations (or conversions!) in Typescript. Type assertions enable you to override default type inference for neutral types. We have discussed about type assertion before.

Typecasting refers to type conversions. While they don’t function similar to other strongly typed languages, they do exist.

We will see more of type assertions and casting after this preface.

Types, you say?

For a basic introduction of “types” - head over to types in Typescript and Javascript types.

Typescript supports -

• built-in types (basic e.g. number, string, boolean,and special types e.g. any, unknown)
• additional types (e.g. collections like enum and even user-defined types)

You define variables with types -

let decimal: number = 1;
let color: string = "indigo";

// anything, really
let notSure: any = "abc";

// collections
let list: number[] = [1, 2, 3];

enum Color {
  Red,
  Green,
  Blue,
}
let c: Color = Color.Green;

It’s all a good world with types until it isn’t. It so happens that -

• you (think you) know more than what the compiler knows. You want to tell compiler that a variable is of a specific type.
• values may need to be moved across types in the course of doing something

Type Assertions and Typecasting

The process of changing types is what is called “type casting”. Typecasting in strongly typed languages like C# allow us to convert types.

string numStr = "123";
int numNum;

bool isParsable = Int32.TryParse(numStr, out numNum);

The code checks whether a given string is a valid number and outputs the number. The “string” or “number” types are treated in a consistent way by both the compiler and runtime engine.

Typescript behaves differently. It is compiled to Javascript, which does not give two hoots about your defined types, and there is no “runtime” to enforce types during execution. All Typescript can do is to apply all its smarts during compilation of Typescript to Javascript code.

Type assertions let the Typescript compiler know that a given variable should be treated as belonging to a certain type. There are no “exceptions” or data restructuring associated with assertions, except minimal validations (we refer this behaviour as “validations that are applied statically”).

But, implicit types do exist during program execution, and type conversion behaves similar to Javascript since the execution engine is, well, Javascript. But, you need to make explicit conversions in Typescript to humour the compiler, and probably, everyone else in your team.

Aside: IMO it is more fun to use implicit conversions that reduce code, confuse people and make it hard to write tests.

When & where to use type casting and type assertion?

Type assertions helps you to force types when you are not in control of them. For e.g. -

1. you are processing user data (with unreliable types)
2. working with data that has changed shape over years (employee code was numeric, now it is alphanumeric :))
3. receiving data from an external program

Consider this example that uses any, a special type that represents any type in Typescript. You convert any to a specific type to process it further -

let whatanum: any = 42;
whatanum = "is this the answer to everything?";
whatanum = true;

We can start with any and use type assertion to denote that the variable is in fact a number.

let whatNum: any = 42;
let reallyNum = <number>whatNum;
console.log(typeof reallyNum); // number

Or, consider this example with unknown, another special type in Typescript -

const clueless: unknown = "1";
const clueNum: number = <number>clueless;

// another format
const clueNumPreferred = clueless as number;

The compiler does not know better about any or unknown variables to process further - so we make the compiler “see” the variables for what they really are.

Typecasting, on the other hand, helps you to convert types and provide consistent (expected) results :). For e.g. -

1. concatenation of a number and string
2. convert arrays of numbers to strings for formatting and display

How do I assert types?

There are two ways to do type assertions.

1. Bracket syntax. e.g. let length: number = (<string>lengthField);
2. Use as. e.g. let length: number = (lengthField as string);

There is no difference between the two ways and the end result is always the same. Note that if you are using JSX you have to use as syntax.

Type conversion in Typescript

Converting specific types is similar to Javascript.

From _ to String

We convert any type to string by using String(x) or x.toString.

console.log(String(42)); //"42"
console.log(typeof String(42)); // "string"

console.log(String(true)); //"true"
console.log(String(undefined)); //"undefined"

From _ to Number

This is so radically different from string.

Number("0"); // 0
Number("abc"); //NaN
Number(true); // 1

There are additional helper functions that, well, help you do strange things -

parseInt("42life"); //42
parseFloat("3.14pi"); //3.14

From _ to Boolean

Convert “stuff” to boolean.

Boolean("a"); // true
Boolean(null); // false

From object to array

Yes, you read that right - let’s see an example of converting object to array in style. Not quite a glaring example of “type conversions”, but apparently, people stare in awe at such code.

const planets: Object = {
  mercury: { name: "Mercury", position: 1 },
  venus: { name: "Venus", position: 2 },
  earth: { name: "Earth", position: 3 },
};
const planetsArr: Array<Object> = Object.keys(planets).map(
  (key: string): string => planets[key]
);
console.log("planetsArr", planetsArr);

/* 
output:
[
  { name: "Mercury", position: 1 },
  { name: "Venus", position: 2 },
  { name: "Earth", position: 3 },
]
*/

The End

We saw type assertions, typecasting and examples of type conversions. Hopefully that has confused you a bit more about the wonderful world of types.

Primitives are fairly easy to type - we have seen this while discussing Typescript and its types.

const num: number = 0;
const msg: string = "hello";

We have seen examples of typed arrays in the same post, but how about all the other collections? How far down the typed rabbit hole are you willing to go?

Arrays

There are two useful notations - pick one, or both.

let num: number[] = [1, 2, 3];
const numToo: Array<number> = [1, 2, 3];

Tuples

Tuples, unlike arrays, have fixed number of elements. In Typescript, we just go about typing all of them.

const life: [string, number] = ["everything", 42];

Objects

Keys can have their own types in Typescript Objects.

const planet: { name: string, position: number } = {
  name: "earth",
  position: 3
};

You can use objects to instantiate the class..

class Planet {
  constructor(public name: string, public position: number) {}
}

const earth = new Planet("earth", 3);

Map

Just like Javascript, a map is an object that stores a key-value pair.

const planet = new Map<string, string>();
planet.set("name", "earth");
planet.set("position", "1");

console.log(planet);
// Map { 'name' => 'earth', 'position' => '1' }

The key and value can have any type - we just happen to use strings for both.

Set

A set is an ordered list of values with no duplicates.

const planet = new Set<string>();
planet.add("earth");

console.log(planet);
// Set { 'earth' }

WeakMap and WeakSet

WeakMap and WeakSet behave like their strong counterparts, but with an object for key. They very much resemble what they can do in Javascript but with types.

Consider this example for WeakMap..

const planet = new WeakMap<{ bodyType: string }, string>();
planet.set({ bodyType: "planet" }, "earth");

.. and, for the WeakSet.

const planet = new WeakSet<{ name: string }>();
planet.add({ name: "earth" });

Access modifiers further a core concept of object oriented programming - ’encapsulation’. The accessibility of variables and members of a class are driven by modifiers and therefore controlled in the programming flow.

Let’s start with a simple class example.

class MathOp {
    public x:number;
    private y: number;
    protected z: number;
}

Public modifier

All variables and members are public by default in Typescript.

So, I may as well type -

class MathOp {
  x: number;
}

.. and no one will leave the chat.

Public variables and members are accessible by anybody outside the class.

const op = new MathOp();
console.log(op.x);
// 1

Let’s add and test a method in the class -

class MathOp {
  x: number = 1;

  double(x: number): number {
    return x * x;
  }
}

const op = new MathOp();
console.log(op.double(3));
// 9

Private modifier

Private modifiers are not accessible outside the class.

class MathOp {
  private y: number = 1;
}

const op = new MathOp();
console.log(op.y);
//  error TS2341: Property 'y' is private and only accessible within class 'MathOp'.

Private variables are accessed through members - if at all they need to be accessed.

class MathOp {
  private y: number = 1;

  getY(): number {
    return this.y;
  }
}

const op = new MathOp();
console.log(op.getY());
// 1

Members behave the same way as variables. Private members are used to perform operations within the class.

class MathOp {
    private myFunc:void {
        // do stuff
    }
}

Protected modifier

Protected members can be accessed within the class and by the derived classes. They cannot be accessed outside of that scope.

class MathOp {
  protected z: number = 3;
}

class newMathOp extends MathOp {
  constructor() {
    super();
    console.log(this.z);
  }
}

const newOp = new newMathOp();

/* output
 3
*/

Protected variables and members are not accessible from extended-class instances as well as class instances.

Static variables and methods are declared with a keyword static.

Static variables

Static variables exist within the class context, and are not carried forward to the object of the class.

Define a static variable like so -

class Human {
  static chaos: boolean = true;
}

The variable value is accessible using the class.

console.log(Human.chaos);
// true

.. but not against the object.

const joe = new Human();
console.log(joe.chaos);
// error TS2576: Property 'chaos' is a static member of type 'Human'

If you need a value in the object no matter the costs, you can always have the two variables with same names.

class Human {
  static chaos: boolean = true;
  chaos: boolean = true;
}

console.log(Human.chaos);
// true

const joe = new Human();
console.log(joe.chaos);
// true

Static methods / members

Static methods behave similar to static variables.

class Human {
  static chaos: boolean = true;
  chaos: boolean = true;

  static checkExists(): string {
    return "exists";
  }

  doubleCheckExists(): string {
    return "exists";
  }
}

console.log(Human.checkExists());
// exists

// console.log(Human.doubleCheckExists());
// error - cannot call a instance member

const joe = new Human();
console.log(joe.doubleCheckExists());
//exists

Note that static variables cannot be called by instance members and vice-versa.

Static variables / members are distinct from their instance counterparts at all times.

Type assertion may not be the most common of the features you employ, but it is invaluable when you are migrating from Javascript. Or, when you have to interact with Javascript libraries or data from external systems in your Typescript code.

Take note of one important thing though - since all Typescript code is compiled to Javascript, any and all assertion is applied at compile time. There is no runtime type assertion.

So, how do you type assert anything?

Type assertion for simple variables

Consider this very simple example -

const one: any = 1;

In the normal course of time, you end up treating one as a number.

const oneOne = one + 1;
console.log("oneOne: ", oneOne);
// 2

But, what if you want to promote one to a string? This is where assertion plays a part - you can tell Typescript to treat one as a string rather than infer it as a number.

const realOne: string = <string>one;
console.log("realOne: ", realOne);
// 1

realOne is a string representation of the any typed one. It can lend itself well to string operations as expected.

console.log(realOne + "two");
// 1two

You could also do the same assertion using an alternate syntax. Use one as instead of <> syntax.

const one: any = 1;
const realOne: string = one as string;
console.log(realOne + "two");
// 1two

Type assertion in objects

Let’s take a look at a recently used example -

const planet = {};
planet.name = "earth";
// error TS2339: Property 'name' does not exist on type '{}'.

As seen in another post planet is treated as a variable with type {} and therefore, planet.name will throw an error.

We can solve this problem by manually inferring the type.

interface iPlanet {
  name: string;
  position: number;
}

const planet = <iPlanet>{};
planet.name = "earth";

console.log(planet);
// { name: 'earth' }

Let’s consider the example below. First, we declare the object and initialize it to an empty object.

const planet = {};

Then, we add the props -

planet.name = "earth";

The above initialization + assignment combination is perfectly valid in Javascript.

But Typescript does not agree with planet.name since the object was declared as type {} (an empty object).

Ideally, the fix will be to declare and initialize with the actual props.

const planet = { name: "earth" };

But, this is not always possible. You may also have to interact with Javascript or migrate large chunks of code, which makes the process more challenging.

A quick fix to the problem is to simply do -

const planet = {} as any;
planet.name = "earth";

Or, if you can, change the prop assignment to a more dynamic property assignment do the below -

const planet = {};
planet["name"] = "earth";

The dynamic assignment functions just like Javascript and you don’t have any type advantages.

Props in an object

Consider this example -

class Fruit {
  readonly name = "apple";
  color = "red";
}

In the code block we have specified the prop name as read-only.

We can very much change the color of an object derived from Fruit.

const apple = new Fruit();
console.log(apple);
// Fruit { name: 'apple', color: 'red' }

apple.color = "blue";
console.log(apple);
// Fruit { name: 'apple', color: 'blue' }

But, we cannot change the name -

apple.name = "orange";
// error TS2540: Cannot assign to 'name' because it is a read-only property

In normal Javascript, you would have defined the property as non-writable using property descriptors to achieve the same effect.

Props in a type

We create types similar to an object, and we can make one or more of the props read-only.

type Fruit = {
  readonly name: string;
  color: string;
};

const newFruit: Fruit = { name: "apple", color: "red" };
console.log(newFruit);
// { name: 'apple', color: 'red' }

newFruit.color = "blue";
console.log(newFruit);
// { name: 'apple', color: 'blue' }

Note that setting name during initialization is allowed, but the prop cannot be changed later.

All props in a type

We can make entire types as read-only by processing it through a Readonly type.

type Fruit = {
  name: string,
  color: string
};

type ReadFruit = Readonly<Fruit>;

let apple: ReadFruit = { name: "apple", color: "red" };
console.log("apple: ", apple);
// apple:  { name: 'apple', color: 'red' }

We get an error if we try to change any prop -

apple.name = "orange";
// error TS2540: Cannot assign to 'name' because it is a read-only property.

In normal Javascript, you can achieve the same effect using Object.freeze().

Consider this example -

function join(a: string): string {
  return a;
}

console.log(join("hello")); // hello

What if we want to use join for strings or numbers? We can do a union type like so -

function join(a: string | number): string | number {
  return a;
}

console.log(join("hello")); // hello
console.log(join(1)); // 1

But, a real world problem would lie in processing the input arguments - not just returning them. Also, the methods and properties of the argument will change within a function based on their types. Typescript solves this problem using Typeguard.

Typeguard is a way if isolating types within an argument in specific blocks. Typescript provides different ways of solving this problem in different situations - typeof, instanceof, literals and in. You can also go ahead and create your own typeguards if none of those satisfy your use case.

typeof

We can build on the previous example -

function join(a: string | number, b: string | number): string | number {
  if (typeof a == "string" && typeof b == "string") {
    return "".concat(a, " ", b);
  } else if (typeof a == "number" && typeof b == "number") {
    return "".concat("".concat(String(a), String(b)));
  }
}

console.log(join("hello", "world")); // hello world
console.log(join(1, 2)); // 12

By simply the process of checking the type with typeof a == "string", Typescript will infer that anything in the block will use a as a string. So, you can easily use a.toUpperCase() within the block but a.toFixed(0) will produce a compilation error.

In the above code block, you could drop the else if and include just an else to get the same result.

function join(a: string | number, b: string | number): string | number {
  if (typeof a == "string" && typeof b == "string") {
    return "".concat(a, " ", b);
  } else {
    return "".concat("".concat(String(a), String(b)));
  }
}

console.log(join("hello", "world")); // hello world
console.log(join(1, 2)); // 12

Typescript will understand that the only other type option for a and b is a number. So it will apply number properties and methods to the variables within the else block.

instanceof

Similar to the use-case for variables described above, instanceof applies itself to user-defined classes and objects.

class Earth {
  color = "blue";
}
class Mars {
  color = "red";
}

function colorPlanet(planet: Earth | Mars) {
  if (planet instanceof Earth) {
    console.log(planet.color);
  } else {
    console.log(planet.color);
  }
}

colorPlanet(new Earth()); // blue
colorPlanet(new Mars()); // red

in

in is similar to instanceof but rather than using an instance of the class, we use a prop of the object to distinguish between two types.

class Earth {
  life = true;
  color = "blue";
}
class Mars {
  color = "red";
}

function processPlanet(planet: Earth | Mars) {
  if ("life" in planet) {
    console.log(planet.color);
  } else {
    console.log(planet.color);
  }
}

processPlanet(new Earth()); // blue
processPlanet(new Mars()); // red

literals

Literals just refer to literal values within an object and to use the possible options as typeguards.

type custHappy = "yes" | "no";

function loadSurvey(sat: custHappy) {
  if (sat == "yes") {
    console.log("happy face");
    // loadPublicSurvey();
    //upSellHell();
  } else {
    console.log("frown face");
    // loadPrivateSurvey();
  }
}

Consider this example -

function printThis(a: string) {
  return typeof a;
}

console.log(printThis("hello")); // string

This function is fine if we want to return the input string for some strange reason. But, what if we want to generalise that function to - say, numbers?

Union type

In Typescript we can simply specify the argument as being string or a number using what is called “union type”.

function printThis(a: string | number) {
  return typeof a;
}

console.log(printThis("hello")); // string
console.log(printThis(1)); // number

The | specifies that the function accepts a string or a number. The function body has to handle any type-specific processing - here we are just returning the input and don’t quite bother with that.

Intersection type

Complementing the ‘union’ feature is what is called “intersection type”.

Intersection types allow us to combine multiple types in one and access any of the features of the individual types.

Consider a different example of two totally real-world classes -

class Tomato {
  constructor(public sweet: string) {}
}
class Chilly {
  constructor(public hot: string) {}
}

Since the classes are freaks of nature by themselves, we want to combine them and have the ability to make use of either properties or methods.

function combine<Tomato, Chilly>(tom: Tomato, chill: Chilly): Tomato & Chilly {
  const mix: Partial<Tomato & Chilly> = {};

  for (const prop in tom) {
    if (tom.hasOwnProperty(prop)) {
      (mix as Tomato)[prop] = tom[prop];
    }
  }
  for (const prop in chill) {
    if (chill.hasOwnProperty(prop)) {
      (mix as Chilly)[prop] = chill[prop];
    }
  }

  return mix as Tomato & Chilly;
}

By using a Tomato & Chilly we are instructing Typescript that “all types herein belongs to us”. In the function, we are simply extracting props from both of the supplied objects and combining them into one object of one type.

We can use the function like so -

const tom = new Tomato("sweet");
const chill = new Chilly("hot");

const rightMix = combine(tom, chill);

console.log(rightMix);
// { sweet: 'sweet', hot: 'hot' }

This is a rather simplistic example involving only props. In the real, real world we could use interfaces and also transfer all the goodness of member functions to the combined entity.

We have previously seen an option to provide optional arguments to a function in Typescript. But, there is more to that to function overloads.

Building on our previous example -

function getSum(i: number, j?: number, k?: number): number {
  j = j || 0;
  k = k || 0;
  return i + j + k;
}

console.log(getSum(1));
// 1

In the example, we have simply made j and k optional arguments and made their value 0 if they are not provided. Although this is evident for someone who looks at the function definition, it is not so for a person looking at the declaration or the auto-complete when initializing this function.

Typescript provides a way to define function overloading during declaration so that we can make full use of the beautiful self-documenting feature.

Consider the same problem in the previous example written in a different way -

function getSum(i: number);
function getSum(i: number, j: number);
function getSum(i: number, j: number, k: number);
function getSum(i: number, j?: number, k?: number) {
  j = j || 0;
  k = k || 0;
  return i + j + k;
}

console.log(getSum(1)); // 1
console.log(getSum(1, 2)); // 3
console.log(getSum(1, 2, 3)); // 6

While the last function is the one that actually gets executed, the developer who consumes this function sees a function with 3 options - provide i alone, i & j, or all of i,j & k.

Function overloading does not cause any runtime overhead, but it is invaluable to further the self-documenting goals of your project.

Duck typing is type safety checks for complex types. It gets its name following the adage -

If it walks like a duck and quacks like a duck, it must be a duck.

Typescript modifies it slightly to -

Don’t check whether it is a duck. If it quacks like a duck.. etc., it must be a duck

Consider an example with a couple of variables of type objects and derived from a class.

class Fruit {
  shape = "round";
}

class Plant {
  shape = "line";
}

const apple: Fruit = new Fruit();
const orange: Fruit = new Fruit();

In the past we have seen that objects are not set to the same rules as everyone else when it comes to specific operations. We cannot directly compare objects to get a valid result - they will be executed by reference rather than doing one-to-one comparison of object entries.

console.log(apple == orange); // false

Any type compatibility checks across objects (derived from same or different classes) will get complicated. But at the same time, we may not really worry about a class to derive the object from as long as the class has all of the properties of the object type.

Now, also mix this background of a problem with an additional complexity. Typescript strives to be compatible with non-typed objects within Typescript and variables from Javascript.

How would you ensure that a new object can interact in a type-safe way with a class and another object under these circumstances?

Enter “duck typing”.

With duck typing, Typescript compares signatures of classes and allows object of one type to be used with an instance of another if the object’s type signature is same as, or is a subset of, the initiating class’s signature.

Let’s see examples!

The following initializations are valid since both Fruit and Flower have the same variable - shape.

class Fruit {
  shape = "round";
}

class Flower {
  shape = "beautiful";
}

const apple: Fruit = new Fruit();
const daffodil: Fruit = new Flower();
const rose: Flower = new Fruit();

Let’s add another class Plant with an additional variable.

class Fruit {
  shape = "round";
}

class Flower {
  shape = "beautiful";
}

class Plant {
  shape = "straight line";
  allWeather = "false";
}

const orange: Fruit = new Plant();

We see that all props of the type Fruit are available when we initialize Plant. So, this becomes a perfectly valid initialization.

However, we cannot do the opposite.

const egg: Plant = new Fruit();
// error TS2741: Property 'allWeather' is missing in type 'Fruit' but required in type 'Plant'.

Plant type has a variable called allWeather, which is not available with the initializing class Fruit. This causes a compile error.

Moral of the story

Typescript does not care about the initializing class as long as it has all the props and methods of the class used for the type. So, keep calm and carry on typing.

Consider the below example of a function that adds two numbers.

function getSum(i: number, j: number): number {
  return i + j;
}

console.log(getSum(1, 2));
// 3

This works fine and as expected, but what happens when there is a discrepancy in number of arguments.

function getSum(i: number, j: number): number {
  return i + j;
}

console.log(getSum(1));
// error TS2554: Expected 2 arguments, but got 1.
// An argument for 'j' was not provided.

The above error is perfect.

Except for the fact that Javascript does not behave this way. So, we can mess up functions, modules and classes when incrementally migrating them to Typescript.

Optional arguments

Fortunately, Typescript has a work-around. You can make the last variable as optional.

function getSum(i: number, j?: number) {
  return i + j;
}

console.log(getSum(1));
// NaN

We did not get compilation errors, but runtime errors continue to happen.

And, you guessed it - there is a work-around for that too. We just revert to the our old friend - argument defaults.

function getSum(i: number, j: number = 0) {
  return i + j;
}

console.log(getSum(1));
// 1

Additional arguments

Additional arguments supplied to the function throws error similar to the previous cases but with a complaint and loud houl about providing more than necessary.

function getSum(i: number, j: number) {
  return i + j;
}

console.log(getSum(1, 2, 3));
// error TS2554: Expected 2 arguments, but got 3

We work-around the problem of additional parameters by taking some help from another old friend of the good guys - rest operator.

function getSum(i: number, j: number, ...k: number[]) {
  return i + j;
}

console.log(getSum(1, 2, 3));
// 3

Consider the below example -

class MathOp {
  public x: number;
  private y: number;
}

const op = new MathOp();
op.x; // no problem

If you try to access the private variable..

op.y;
// Error: Property 'y' is private and only accessible within class 'MathOp'

What does private even mean?

From our earlier definitions, the behaviour seems ok.

Or, is it?

Just compile the above code block to JS.

tsc test1.ts

And, the compiled Javascript file is -

var MathOp = /** @class */ (function() {
  function MathOp() {}
  return MathOp;
})();
var op = new MathOp();
op.x; // no problem

There is no mention of variables x and y in the class since they are just props. These props of the function can be dynamically defined and created.

There is nothing in the compiled Javascript that will have a problem running the script even if something is defined as private.

But, private does prevent successful compilation.

End result: we are pretty much covered with the private variables but be aware of compile and runtime differences in behaviour.

public can be dropped from the statements

You can as well rewrite the Typescript file as -

class MathOp {
  x: number;
  private y: number;
}

const op = new MathOp();
op.x; // no problem

Variables and methods are public by default - you can save on your typing a bit by dropping the public keyword altogether.

At a high-level we can classify types as built-in (basic & special ) and additional types including user-defined types.

Built-in Types (Basic)

Similar to Javascript implicit types, we have number, string, boolean to form the three core built-in types.

let num: number = 1;

let planet: string = "earth";

let isHappy: boolean = true;

We also have null, and undefined as additional basic built-in types.

let nothing: null = null;

let undef: undefined = undefined;

You could technically do this..

const fruit: any = null;
const flower: any = undefined;

// we'll deal with any in a bit

.. and also this (when a flag called --strictNullChecks is not specified during compilation) -

const fruit: string = null;
const num: number = undefined;

Oh, and symbol is also a valid type.

let sup: symbol;

Built-in Types (Special)

There are four types that have special function within Typescript.

any

any represents any type. It gives super powers to Typescript and makes it play well with Javascript. any tells Typescript to do a type inference on a variable.

For e.g. ,

const fruit: any = "apple";
// or simply, const fruit = "apple"
console.log(typeof fruit); // string

const num: any = 123;
console.log(typeof num); // number

any can be your best friend. You can convert your entire Javascript to Typescript by simply changing extension and continue using it as before. You could then incrementally add Typescript powers to the script.

Since any variable without a type is assumed as type any, Typescript can also interact Javascript without a hitch.

unknown

unknown was introduced in Typescript v3. It is type safe any - a variable with type unknown can be assigned value of any type.

const x: unknown = 1;
console.log(typeof x);
// number

But, unknown cannot be assigned to any other type other than unknown.

const x: unknown = 1;
let y: number = x;
// Error: Type 'unknown' is not assignable to type 'number'.

.. and, no operations are allowed for unknown data type against a known type.

console.log(x + 1);
// Error: Operator '+' cannot be applied to types 'unknown' and '1'.

void

As you expect, void has its duty cut out with functions - it primarily means no type.

function printThis(msg): void {
  console.log(msg);
}

printThis("hello");

void can also be used against mere variables, but you would have to answer to yourself whether you are addressing a galaxy-level problem doing that. These variables are not assignable to valid values thereon.

const a: void = null;
// the above will throw compile error when --strictNullChecks flag is used

const b: void = undefined;
// ok, but to what effect?

never

never signifies values that never occur. That can be confusing if you’re not into quantum mechanics, but let me explain.

Consider a function that always throws error - it does not need to return anything.

function thrower:never(){
    throw "I throw stuff"
}

So, how can it distinguish itself from void?

void is for functions where you can reach the end of function. While never is for functions where end of function is never reached.

function whatAManWants:never() {
    return gobble(resources)
}

Additional Types

‘Additional type’ is just a bucket to include all the other types other than the primitive types defined above. Typescript supports other types including user-defined types like those described below.

Collections

Collections can include arrays and tuples. Each of those collections can have elements with a specific type or a mix of types using any.

const fruits: Array<string> = ["apple", "orange", "pear"];
const primes: Array<number> = [1, 2, 3, 5];

// any

const universe: Array<any> = ["life", 42];
console.log(universe);
// [ 'life', 42 ]

A tuple with fixed number of elements has those elements with specific types.

let everything: [string, number];
everything = ["life", 42];
console.log(everything);
// [ 'life', 42 ]

Special data type: enum

enum is not like anything that you have seen so far.

1. you define enum
2. a variable of the defined enum type can be assigned to a value within the enum

Consider the below example -

enum Planets {
  mercury = 1,
  venus = 2,
  earth = 3
}

const earthPos: Planets = Planets.earth;
console.log("earthPos: ", earthPos);
// 3

Object

As in Javascript, anything that is not primitive is an object.

The following code is valid..

const apple: Object = { name: "apple", color: "red" };
console.log(apple);
// { name: 'apple', color: 'red' }

But, depending on your situation, may not be useful for type assertion against the object’s props (like Array<string> for example).

Typescript behaves like a language with built-in support for OOP concepts, and does not carry the quirks of Javascript in that respect.

Classes and Objects

Define classes and objects like how you define in any of the popular OOP languages.

class Fruit {
  public name: string;
  private grownIn: Array<string>;


  constructor(name: string, grownIn: Array<string>) {
    this.name = name;
    this.grownIn = grownIn;
  }

  getGrownIn(role: string): Array<string> {
    if (role == "admin") return this.grownIn;
    else return [];
  }

  private
}

let appleFruit = new Fruit("apple", ["India", "China"]);

console.log(appleFruit.name);
// apple

We have defined a simple class ‘Fruit’ and provided it with -

• a public variable of type string - name
• a private variable of type array of strings - grownIn
• constructor to set variable values from initialization
• method to get value of getGrownIn

We define appleFruit as an object of the class Fruit and initialize it with values for both name and grownIn.

Straight off the bat we see the feature of private variables, which are a thing only in the most recent Javascript standard.

console.log(appleFruit.grownIn);
// Error: Property 'grownIn' is private and only accessible within class 'Fruit'.

We also see how auto-complete works beautifully while typing in all this code.

Use interfaces

We can level-up the above code by using interfaces for additional abstraction.

interface Plant {
  plant?: string;
  type?: string;
}

We have specified two variables and both are optional.

Change the class to implement this interface.

class Fruit implements Plant {
  public name: string;
  private grownIn: Array<string>;

  constructor(name: string, grownIn: Array<string>, public plant: string) {
    this.name = name;
    this.grownIn = grownIn;
  }

  getGrownIn(role: string): Array<string> {
    if (role == "admin") return this.grownIn;
    else return [];
  }
}

let appleFruit = new Fruit("apple", ["India", "China"], "Apple Tree");
console.log(appleFruit.name);

Similar to other languages you can extend a parent class in the interface.

class PlantMatters {
  // ...
}

interface Plant extends PlantMatters {
  // ...
}

What is Typescript?

Typescript is a typed Javascript.

No, I am kidding - it is more than that. Typescript is not only strongly typed language that acts as a super-set of Javascript, but also is compiled and object oriented language. What distinguishes Typescript is not the language alone but the tooling that surrounds the language.

Typescript was invented and popularised by the good folks at Microsoft. It is in active development and continues to add amazing features with each release.

The Typescript ecosystem makes you welcome as a Javascript developer, does not impose itself but gives you really powerful tools if you want dive right in. Your development is going to be more standardized, faster, and your code is going to be friendly with everyone in the team.

I see a great value for Typescript in a team setting or for components and libraries that are used by everyone and their dogs.

Why another language?

You should use Typescript because it is and is not another language at the same time.

Strong typing may seem daunting at first but the amount of errors it catches by itself and the ease of development(?) more than makes up for the initial hiccups and the extra typing.

There are of course a host of features that make Typescript invaluable and my objective here is not to cover them all. Key features include -

• Compiled language - catch more errors at compile and not at runtime
• Good support for object oriented features (at least during development / compilation)
• Runs seamlessly across environments - web, operating systems and devices
• Typing everything can be the most beautiful form of self-documenting everything
• Easier to code!

But, I am a Javascript fanatic

Typescript is not a new language housed in an island and its own ecosystem. It coexists with Javascript.

• Typescript is Javascript++. Typescript gets compiled to Javascript for execution when required
• You can use both Javascript and other Typescript libraries within Typescript. You can use Typescript libraries within Javascript too
• Migrations can be incremental. You can use inferred typing and get started on Typescript with existing code

Get started

Getting started with Typescript is easy. Let us setup the development environment first.

npm install -g typescript

Then, create a new file “hello.ts”.

// hello.ts

console.log("hello world");

If you now do -

tsc hello.ts

.. you will get a hello.js file. This is a JS compiled version from your Typescript file.

Since we did not quite use any Typescript specific stuff, our JS file is same as TS file.

console.log("hello world");

You can run the JS file to the same end result as a normal JS file.

Alternatively, you can create the TS file and simply execute two commands in one go -

tsc class1.ts | node class1.js

Or, use a better utility built to the purpose.

Install ts-node

npm i -g ts-node

Now, you can use nodemon to watch for changes in your Typescript file, generate Javascript when required and execute the Javascript - in one seamless way.

nodemon hello.ts

We do not see the intermittent file “hello.js” using this method but it is recommended for development purposes only.

Write a better typescript example

Create a new file sum.ts.

function getSum(x: number, y: number): number {
  return x + y;
}

const sum: number = getSum(1, 2);
console.log("sum: ", sum);
// 3

You may observe that when you type getSum(, the autocomplete will suggest the type or arguments and the return. This auto-suggestion does not seem all that important, but is super useful when you are working in teams or have to work with third party libraries.

Next, try to do -

const sum: number = getSum("a", 2);
// TSError: ⨯ Unable to compile TypeScript:
// class1.ts:5:28 - error TS2345: Argument of type '"a"' is not assignable to parameter of type 'number'

You see a couple of significant things -

1. Editors like VSCode catch the error - no compilation or execution required. The ‘a’ argument is underlined with red squiggly in the hope that you correct the error
2. Even if you ignore the editor error, Typescript does not compile the file but throws the error outlined above

Also see

• Typescript in 5 minutes.