photo-1549109926-58f039549485

Do you search for a cleaner code in TypeScript? You can start by using TypeGuards!

## What are type guards?

**Type guards** in **TypeScript** are special functions which are used to detect if `any` or `unknown` types are of a certain type.

How many times did you checked if a variable is a `string` or a `number`? Well, stop doing it by hand everytime, use **type guards**!

Being functions, those **type checks** are reusable and will prevent you from explicitely type cast anything in your code, leaving everything cleaner and easier to maintain and reuse.

## How can they help you?

Well, **TypeScript** is a superset of **JavaScript**, isn't is? JavaScript, since is **dinamically typed**, could be quite dangerous if you do not type checking.

Type checking is one of the **most boring** and usually messier part of any codebase.

**Type guards** can help you by reducing your code base and reusing every type check you make.

## Example using type guards

Instead of writing checks like this every time, which mess up your code

```ts
interface IUser {
    name: string;
    surname: string;
}

function fullName(arg: unknown): string {
    if (typeof arg === 'object' && arg !== null && 'name' in arg && 'surname' in arg) {
        const name = typeof (<IUser> arg).name === 'string' ? (<IUser> arg).name : '';
        const surname = typeof (<IUser> arg).surname === 'string' ? (<IUser> arg).name : '';
        
        return [name, surname].concat(' ');
    }

    return 'unknown';
}
```

use a **type guard** like this!

```ts
interface IUser {
    name: string;
    surname: string;
}

function isUser(arg: unknown): arg is IUser {
    return (
        typeof arg === 'object' &&
        arg !== null &&
        'name' in arg &&
        'surname' in arg
    );
}

function isString(arg: unknown): arg is string {
    return typeof arg === 'string';
}

function fullName(arg: unknown): string {
    if (isUser(arg)) {
        const name = isString(arg.name) ? arg.name : '';
        const surname = isString(arg.surname) ? arg.name : '';
        
        return [name, surname].concat(' ');
    }

    return 'unknown';
}
```

Great, cleaner and more reusable code! 

Note that everytime you will have to do a check on a type implementing the `IUser` interface, you will have only to use the proper **type guard** function!

## Advanced typeguards

You can of course write advanced typeguards for more structured data in order to grant if a variable is of a type or not.

For example you could check if a variable is a `Person` like this

```ts
// primitive-typeguards.ts
export function isNumber(arg: unknown): arg is number {
  return typeof arg === 'number';
}

export function isString(arg: unknown): arg is string {
  return typeof arg === 'string';
}
```

```ts
// Person.ts
import { isNumber, isString } from './primitive-typeguards';

export interface Person {
  age: number;
  name: string;
}

export function isPerson(arg: unknown): arg is Person {
  return (
    typeof arg === 'object' &&
    'age' in arg &&
    'name' in arg &&
    isNumber((arg as any).age) &&
    isString((arg as any).name)
  );
}
```

```ts
// app.ts
import * as person from './Person';

export default function getPerson(surname: string, name: string): Promise<person.Person | null> {
  const json = await (await fetch(`endpoint/${surname}/${name}`)).json();
  
  return person.isPerson(json) ? json : null;
}
```

## Hint!

When you write your application using **Domain Driven Development** (aka **DDD**), it's a good practice to add, inside your entity's file, the proper **type guards** functions.

Another example for you

```ts
export class User {
    public name: string = '';
    public surname: string = '';
    
    public constructor(user: Partial<User>) {
        Object.assign(this, user);
    }
}

export function isUser(maybeUser: unknown): maybeUser is User {
    return (
        typeof arg === 'object' &&
        arg !== null &&
        'name' in arg &&
        'surname' in arg
    );
}
```


Clean TypeScript code with type guards

Green hills are greeneen

As a functional programming library, tiinvo can help a lot for clean code

If your code is filled with `if/else` or `try/catch` statements maybe it could be time to clean it up.

One of the most effective ways to get a cleaner code is to use the __functional programming paradigm__.

The benefits of using functions for conditional flows are many and the greatest one is the possibility to reuse conditions all over your codebase making it D.R.Y. (aka the dont repeat yourself).

There are dozens of libraries written both in __JavaScript__ or __TypeScript__ for functional programming and this time we will give a look a __tiinvo__.

You can install tiinvo with both `npm` or `yarn`.

```bash
npm i tiinvo
# or if you use yarn
yarn add tiinvo
```

## Handling try/catch

Try catch are used to prevent your code crashing when an uncaught `Error` is thrown.

A normal try/catch expression usually looks like this:

```ts
function isString(input: unknown): input is string {
  return typeof input === 'string';
}

function thisWillThrow(input: unknown): string | never {
  if (!isString(input)) {
    throw new TypeError('input must be a string');
  }
  
  return input;
}

export async function handler(context) {
  try {
    const param = thisWillThrow(context.req.body.foo);
    
    return {
      status: 200,
      body: {
        param,
      },
    };
  } catch (error) {
    return {
      status: 500,
      body {
        error,
      },
    };
  }
}
```

Too many curly braces indeed.

Using __tiinvo__, you can first avoid the __try/catch__ construct, invoking your function safely, then you can decide what to do with your `Result`.

Let's rewrite it

```ts
import { TryCatch } from 'tiinvo';

function createResponse(status, body) {
  return {
    body,
    status,
  }
}

function isString(input: unknown): input is string {
  return typeof input === 'string';
}

function thisWillThrow(input: unknown): string | never {
  if (!isString(input)) {
    throw new TypeError('input must be a string');
  }
  
  return input;
}

export async function handler(context) {
  return TryCatch(thisWillThrow, context.req.body.foo)
    .mapOrElse(
      error => createResponse(500, { error }),
      param => createResponse(200, { param }),
    );
}
```

Cleaner. Note that `TryCatch` can call your function with the needed signature arguments.

You can also handle `async` functions with `TryCatchAsync`.

```ts
import { TryCatchAsync } from 'tiinvo';

async function catchy() {
  throw new Error('💥💥💥');
}

export async function maybeExplodes() {
  return (await TryCatchAsync(catchy)).mapOrElse(
    () => 'exploded',
    () => 'wow is safe',
  );
}
```

## Handling if/else statements with `Either`

The __if/else__ statements are used to control the execution flow of your code. There are different constructs for controlling code flow, but the most used is the `Either` construct, which represents a value that could be considered falsy (left) or truthy (right).

To make an example, give a look at the code below.

```ts
// file a.ts
// could possibly throw, forcing us to use a try/catch
export function doStuff(num: number): number | never {
  // if statement
  if (num % 2 !== 0) {
    throw new Error('number is not even');
  }
  
  return num;
}

// file b.ts
import { doStuff } from './a.ts';

doStuff(2);
doStuff(4);
// throws, stops execution. To avoid it, we should use a try/catch, but not today 
doStuff(5); 
doStuff(6);
```

Rewriting the example above using tiinvo will look like this

```ts
// file a.ts

import { Either, Err, Left, Ok, Right } from 'tiinvo';

// yep I know, a really silly example
function isEven(num: number): Either<number, number> {
  return num % 2 === 0 ? Right(num) : Left(num);
}

export function doStuff(num: number): Result<number, Error> {
  return isEven(num)
    .fold(
      () => Err('number is not even'),
      num => Ok(num),
    )
}

// file b.ts
import { doStuff } from './b.ts';

doStuff(2); // returns Ok(2)
doStuff(4); // returns Ok(4)
doStuff(5); // returns Err() so we can handle without a try catch and without blocking execution
doStuff(6); // returns Ok(6)
```

## handling possible result from an operation

Error handling is one of the worst parts of programming. You have to catch them all® using the `try/catch` syntax, which sometimes is a lot messy.

To avoid this, you can use the `Result` data type, which handles both an `Err` if something did go wrong or an `Ok<T>` if something went correctly.



```ts
// a.ts
export function isEven(num: number): number | null {
  return num % 2 === 0 ? num : null;
}

// b.ts
import { isEven } from './a.ts';

export async function getCount() {
  try {
    const result = await fetch('/my/url');
    const json = await result.json();
    
    if (isEven(json.count)) {
      return { count: json.count };
    } else {
      return { count: 0 };
    }
  } catch (error) {
    return { count: 0 };
  }
}
```

You can rewrite like this

```ts
// a.ts
import { Some } from 'tiinvo';

export function isEven(num: number): Some<number> {
  return Some(
    num % 2 === 0 ? num : null
  )
}

// b.ts
import { TryCatchAsync } from 'tiinvo';
import { isEven } from './a.ts';

function count(num: number) {
  return { count: num };
}

export async function getCount() {
  const result = await TryCatchAsync(fetch, '/my/url');
  const json = await TryCatchAsync(result.json);
  
  return json.mapOrElse(
    () => count(0),
    num => isEven(num).mapOr(count(0), val => count(val))
  );
}
```

## using `Option` for optional values

`Option` is similar to the `Maybe` monad, but is used to express a value that is optional, therefore it's name. The implementation of `Option` is taken from __rust__ language __std::option__. Unlike `Maybe`, which treats every falsy value like `Nothing`, `Option` flatterns undefined, null, NaN or invalid Dates as `None`.

```ts
import { Option } from 'tiinvo';

export interface IUser {
    name?: string;
    surname?: string;
    email?: string;
}

export type IMappedUser = Record<IUser, Option<string>>;

// maps IUser to IMappedUser
export function map(user: IUser): IMappedUser {
    return Object.keys(user).reduce(
        (collector, key) => (
            {
                ...collector,
                [key]: Option(user[key])
            }
        ),
        {}
    );
}

export function isValid(mappedUser: IMappedUser): boolean {
    return mappedUser.email
        .and(mappedUser.name)
        .and(mappedUser.surname)
        .isSome();
}

isValid(
    map({ email: 'john.doe@gmail.com' })
); // false

isValid(
    map({ email: 'john.doe@gmail.com', name: 'john' })
); // false

isValid(
    map({ email: 'john.doe@gmail.com', name: 'john', surname: 'doe' })
); // true
```

The try/catch and if/else hell

photo-1461354360854-e33a1d6f7905

A __singleton__ is a common __design pattern__ in __object oriented programming__.

This pattern forces the program to have only one instance of an object at a time.

In modern JavaScript and TypeScript, lot of developers could create a singleton writing a class and then exporting a single instance of it.

```js
class Foo {
  constructor() {
    this.bar = 10;
  }

  decrement() {
    this.bar--;
  }

  increment() {
    this.bar++;
  }
}

export default new Foo();
```

Guess what, you are doing it wrong.

In node.js modules are singleton by nature, so you does not need to write a class to it!

Let's rewrite it again:

```js
let bar = 10;

function decrement() {
  bar--;
}

function increment() {
  bar++;
}

export default {
  bar,
  decrement,
  increment,
}
```

Doing this way is simple and you do not have to create a class (and the machine will not have to instance a unused prototype) and you will avoid to create new instance of `Foo` class. 


Creating singletons in node.js

test

What if we are making a great mistake? Finding value where there is some.

I started writing code (for web development) in 2002; HTML, CSS and JavaScript were still embryos compared to today, __Front end development sucked a lot__, because every browser had it's own specific API, and they were still lacking of a lot of things that nowaday we love, so it was hard to deliver something beautiful for our customers.

Nowadays we have ES6 and TypeScript for our codebase, webpack for bundling stuff, Angular or React or Vue for web applications and web sites development, Redux and similars (with the whole related ecosystem) for "state" management and we can rely on thousands of libraries for everyday need.

We have a standardized CSS/HTML5 API all across the browsers (and it will be better in 2020/2021 thanks to Microsoft for ditching IE and for using chromium in Edge), we have dozen of services for delivering content, creating our restful APIs and hosting our applications.

It's the golden age of Lego® Software, you just need to __collect__ your bricks, __combine__ them and __deliver__ stuff.

Technically speaking it's all rainbows and unicorns, but for software development it is not.

Lot of developers are missing something, which in my honest opinion should be our mantra: __the value in our work is not to be found in solving our technical issues, we are paid to deliver something useful for our customers__. 

Out clients do not care about technological stuff because they just want a __product__ which __cost less__ than others, __adds value__ to their business and help them to make a __profit__.

__Profit__.

Repeat with me: __profit__.

In IT business, __code is a cost__. A lot of developers do not often remember this or worst do not think about it.

__Over engineering__ is behind the corner thanks to __our technical onanism__, we are more often introducing it and it is harder to avoid.

### Code value < delivered value

We are taking great care of our code, and this is partly good: __good coding__ leads to __lower maintenace costs__, __better quality__ and obviously, more __stable software__. What a lot of developers is not focused on is delivering it. __Delivered__ (and paid) __is better than perfect__.

A lot of devevelopers, particularly on the front-end side, stop at this point. There is the belief that developer's work should only consist in knowing syntax, frameworks, last coding trends (ugh, this sounds awful, but you know, redux everywhere) and more hopefully data structures (not always, but this is another matter).

This leads to find perfection where perfection is not needed, and leads devs to prove themself with highly complex codebases when there is no need to have complexity. Technical onanism again.

Our work is to build valuable working stuff, and remember, the customer does not care if we use the latest trendy UI library or latest front end framework; the customer want it delivered with any sort of problems.

We are responsible for our front-end aplocalypse.

### How to survive this front-end apocalypse

Well, there is no way to survive.

Really.

Until we will have a better support for custom elements, and until lot of developers will know libraries and frameworks better than the native platform, there will be no way to escape the apocalypse.

What I always suggest to younger devs, is to keep is simpler as possible, and to put more effort on data structures and patterns than on coding and adding libraries. 

Another suggestion is to remember that until your code works, is clear enough and it does not need more than minutes to refactor, it's great code, who cares if it's written in 2002 javascript or if you use old libraries.

__Testing.__

Do not test everything. Test only what you really need to test. 100% tests coverage is a unicorn: everybody love unicorns, everybody know how they look like but nobody as seen one before, so stop complicating your life.

__Stop using the latest trendy libraries.__

This is the hardest part, but if you and your team feel safe using a library, stick to it until it will be really old (angular.js anybody?). Remember that you have to deliver, so keeping the focus only on a small set of libraries will help you, your team and newcomers to write faster and in a better and safer way. 

__Keep it simple__

If you come from java to typescript, stop reasoning like if you are writing java.
If css in js does not give you a real advantage, use old plain css.
If you have to build a landing page, do not use vue or react, write HTML, CSS and javascript. It will be faster, safer and cheaper.
If you struggle finding a good way to organize your code, maybe you are over-engineering.

Do yourself a favor: do not solve a problem introducing another one.







I am Paolo Roth

Latest from my blog:

Clean TypeScript code with type guards

The try/catch and if/else hell

Creating singletons in node.js

Solving a problem with another one.

Latest projects I have worked on: