DEV Community: Alex Menor

Do you really know TypeScript? (4): Type assertions

Alex Menor — Thu, 06 Jan 2022 18:25:55 +0000

In this post (the last of the series 😢) we are going to understand type assertions and compare them against type declarations.

What do you use type assertions for?

There are situations where you know more than TypeScript can infer.

let item: Item = {...}

type Item = {
  name: string
}

type FileItem =  Item & {
  extension: string
}

// We know for sure that item
// is also a file
printFile(item as File)

Golden rule for using assertions

You can only assert from one type to another if either type is a subset of the other. 🧐

type Car = {
  numOfDoors: number
}

type Airplane = {
  numOfEngines: number
}

const car: Car = {numOfDoors: 5}

// Conversion of type 'Car' to type 'Airplane' may be a mistake
// because neither type sufficiently overlaps with the other. 
const airplane = car as Airplane

An exception to this rule is when using unknown or any.
You can use these to bypass it:

unknown because is the universal set
any because disables the type checking

const airplane = car as unknown as Airplane

Prefer type declarations to type assertions

This is a mistake that I've seen a lot!

type Car = {
  numOfDoors: number
  numOfAirbags: number
}

// Error: Property 'numOfAirbags' is missing
const car: Car = {numOfDoors: 5}

// No error
const car = {numOfDoors: 5} as Car

When you use type assertions you are telling TypeScript to get out of the way, with type declarations you are making your intentions clear so it can help you.

Is `as const` a type assertion?

It is not.
Despite having a similar syntax, as const is used to hint the type system about values being immutable.

It is very situational, but could be useful for using the values of an array as literals, for example:

const coolBands = ['Oasis', 'AC/DC', 'Foo Fighters'] as const

// type CoolBands = "Oasis" | "AC/DC" | "Foo Fighters"
type CoolBands = typeof coolBands[number]

Or for using the values of an object:

const coolBandsAndSingers = {
  'Oasis': 'Liam Gallagher',
  'AC/DC': 'Brian Johnson',
  'Foo Fighters': 'Dave Grohl'
} as const

// type CoolBands = "Oasis" | "AC/DC" | "Foo Fighters"
type CoolBands = keyof typeof coolBandsAndSingers

// type CoolSingers = "Liam Gallagher" | "Brian Johnson" | "Dave Grohl"
type CoolSingers = typeof coolBandsAndSingers[CoolBands]

As it is the last post of this series, I also want to go through some topics that couldn't get a post for their own.

Don't type everything!

I did it, and probably so did you.

It is not bad, but can make the code too verbose and therefore harder to read.

As a rule of thumb, you should type very well:

Function and method signatures (parameters and return types)
Variables and constants when using object literals, to take advantage of excess property checking.

In a TDD like spirit, you should know your input and output types before implementing a function/method, so typing it from the beginning makes it easier for you to implement it.

Typing return types usually avoids implementation errors, specially if your function has many "paths".

Don’t use uppercase variants of primitive types

Probably you noticed that String or Number exist and wonder if you should use them as types.

The answer is no. Just stick to lowercase types for primitives string, number, boolean, etc.

These uppercase variants exist primarily for convenience, for example:

// charAt is not a property of
// the string primitive
"hey".charAt(1)

JavaScript wraps the string primitive in String under the hood and uses the charAt method of String and then throws that object away.

// These wrappers don't have behave 
// as primitives

new String('hey') === new String('hey')

'hey' === new String('hey')

It's been a pleasure to write this series and I wish you a very productive experience with TypeScript 🙂

Thanks for reading!

Resources to go deeper

Do you really know TypeScript? (3): Types and interfaces

Alex Menor — Sun, 02 Jan 2022 10:52:25 +0000

One of the things that you will do the most with Typescript is to define the shape of objects with type or interface. For that reason, understanding both well will make your TypeScript better quickly.

Let's see their main differences aside of the syntax, common patterns and surprising behaviours.

`type` can be used for more things

While interface is used just to define the shape of objects, type has other use cases.

type Pet = 'Cat' | 'Dog'

type CoolNumbers = 3.1416 | 4 | 100

Interface merging

You should be aware of this one.

interface DesktopFile {
  icon: string;
}

interface DesktopFile {
  extension: string;
}

// Error: Property 'icon' is missing in type '{ extension: string; }' 
// but required in type 'DesktopFile'.
const file: DesktopFile = {
  extension: 'pdf',
}

It can be surprising that you can redeclare an interface and merge them!

This is also known as "interface augmenting" and can be desirable in some situations but is definitely unusual in other languages.

Note that using Type would result in an error.

Discriminated union

Also known as "tagged union", is a frequent pattern in TypeScript.

It can be weird if you are used to polymorphism using classes, but since TypeScript's types disappear at runtime, you need to do things a bit different.

type File = {
    kind: 'file';

    name: string;
    extension: string;
}

type Folder = {
    kind: 'folder';

    name: string;
    filesInside: number;
}

type DesktopItem = File | Folder

const item: DesktopItem = {...}

if (item.kind === 'file'){
    // TypeScript knows that the properties
    // of the type File are defined here
}

This can be used like instanceof in other languages.

Union of types vs types of unions

Generally prefer union of types.

type Vehicle = {
    kind: 'motorcycle' | 'car'

    numberOfWheels: number 
    numberOfAirbags: number | undefined
}

const vehicle: Vehicle = {...}

if (vehicle.kind === 'car'){
    // TypeScript still thinks that
    // numberOfAirbags could be undefined
}

If we used union of types instead, like in the "discriminated union" example, TypeScript can be sure that the Car properties are available.

Excess property checking

This is a mechanism that can mess your mental model of structural typing when using type and interface.

interface Cat {
  name: string;
  whiskersLength: number;
}
const cat: Cat = {
  name: 'Uxia',
  whiskersLength: 6,
  bestFriend: 'Nina',
// ~~~~~~~~~~~~~~~~~~ Object literal may only specify known properties,
//                    and 'bestFriend' does not exist in type 'Cat'
};

From a structural typing point of view it is valid as the defined object contains at least the properties declared for Cat.

This is excess property checking complaining though.

Check out this case:

type Person = {
    name: string;
    zipCode?: string;
}

const randomGuy: Person = {
    name: 'Pedro',
    zip: '45420',
}

Excess property checking quickly points out an error that we could've spent too much time looking for otherwise.

Note that this check only happens when using object literals.

Should I use `type` or `interface` then?

I find type easier to reason about and more readable.

One exception would be when extending types:

type Flyable = {
  fly(): void;
}

type Airplane = Flyable & {
  ...
}

interface Helicopter extends Flyable {
  ...
}

Also, as we saw earlier, "interface augmenting" can be unfamiliar to many people.

Be aware of their differences, try to make your team agree in their uses for the sake of consistency and you will be fine.

Resources to go deeper

Do you really know TypeScript? (2): Being strict

Alex Menor — Mon, 27 Dec 2021 14:29:10 +0000

Strict settings

The TypeScript transpiler has an overwhelming set of options 🥵, but don't worry, you don't have to know them all.

Though, you should know these two really well:

noImplicitAny
strictNullChecks

When noImplicitAny is enabled all variables must have a known type.

function greet(name) {
    return `Hello, ${name}`
}

If you hover over the function (and your IDE has TypeScript capabilities) you will see that it infers that name is of type any.

We can say that name is implicitly of type any, and if noImplicitAny is disabled TypeScript will rightfully complain 🙂

As we'll see more in depth later, any bypasses TypeScript's type checks, making values of the any type assignable to anything.

Using the any type should generally be your last resort and if you really need to use it, you have to do so explicitly if noImplicitAny is enabled.

Although noImplicitAny enables you to make the most out of TypeScript, it can be tough to have this setting enabled if you are migrating your codebase from JavaScript, for example.

As we already mentioned, you can see types in TypeScript as sets of values.

strictNullChecks controls if null and undefined are part of every type.

 const jame: Person = null

 // It'll throw "cannot read 'greet' of undefined" at runtime
 jame.greet()

This code is going to throw an error when you execute it.
But, with strictNullChecks enabled, TypeScript will tell you at compile time instead:
Type 'null' is not assignable to type 'Person'.

There are more "strict" settings that modulate how picky TypeScript is and you can turn them all on with strict: true.
I would advise you to do so, specially if you are starting a project from scratch.

Handling type edge cases

Before introducing the empty and universal sets as promised, we have to talk about any, which is often perceived as the universal set.

What should I use any for, then?

TypeScript is a gradual type system, you can type some parts of your code and leave others untyped. any enables that, disabling the type checks.

You can assign a value of the any type to anything
You can assign anything to a variable of the any type

any doesn't fit in the "type as a set of values" model, since a set cannot be a subset and a superset of everything at the same time.

// No errors even with strict: true
const age: number = "4" as any
const name: any = 3.1416

Be specially cautious when it comes to using any as a return type as it can spread to other well typed parts of your code that make use of said function.

The universal set

Important points of unknown:

Any type is assignable to unknown because every type is a subset of it.
But unknown is not assignable to any type but itself (or any) because it is not the subset of any other type.
Attempting to access a property on a value of the type unknown is an error.

The last point is key, specially when using it as an alternative to any for edge cases when we really don't know the return type of a function, for example.
When using unknown, the untyped code doesn't spread as we need to narrow the types in it in order to use it.

Besides narrowing it with an assertion, some libraries use generics for this:

function query<T>(q: string): T;

const result = db.query<User[]>('select * from user')

The empty set

The never type is the opposite of unknown:

Nothing is assignable to never because no set is a subset of the empty set.
never is assignable to everything, because the empty set is the subset of every set.

The use of never is not as frequent as unknown but it does have an use case that I like a lot called exhaustive type checking:


type SpanishChampionsWinners = 'Real Madrid' | 'Barcelona'


function getChampionsCount(team: SpanishChampionsWinners): number {
  switch (team) {
    case 'Real Madrid':
      return 14;
    case 'Barcelona':
      return 5;
    default:
      const exhaustiveCheck: never = team;
      throw new Error(`We forgot: ${team}`);
  }
}

If one day "Atlético de Madrid" wins a Champions title, adding it to the SpanishChampionsWinners type will make this code complain since no value is assignable to never.

Things to remember:

Be as strict as possible with your TypeScript settings and know noImplicitAny and strictNullChecks well.
Understand that any does not fit in the "types as sets" model, being a mechanism to avoid types in parts of your code.
Try to isolate the untyped parts of your code and be aware of the any spreading.
Understand why unknown is preferable to any when handling edge cases.
Get the idea of never and use it for exhaustive checking.

Resources to go deeper

Do you really know TypeScript? (1): Thinking in sets

Alex Menor — Sat, 25 Dec 2021 17:14:29 +0000

I know many people, including myself, whose first experience with TypeScript was to write annotations in some variables and to add as any until the transpiler stopped complaining.

But at some point you realize that you really should dig a little deeper into TypeScript and finally understand those errors.

It's true that you can technically build the same websites/systems with and without TypeScript, but its benefits are huge:

Catch errors at compile time instead of at runtime
Autocomplete ("it was user.phone or user.phoneNumber?" 🤔)
Language services (enabling some IDE's refactors for example)
Better domain modelling

Using TypeScript is not only investing in the code's maintainability, it is also investing in the developer's productivity.

Okay, you are (or were already) convinced that TypeScript is worth learning, what is this series for?

In this series I will go through many aspects of the language that were not obvious to me even after having already done some projects with it.

You will stop wrestling with TypeScript 🤼‍♀️

Seeing types as sets of values

// what can we assign to it?

const foo: Bar = ???

We can assign any value that belongs to a subtype of Bar.

One cool thing of this system is that you can use set operators (among others) to create new types.

For example the union operator: number | string is the set of all numbers and strings.

Structural typing

To know if a value belongs or not to a type, TypeScript only focuses on the shape that it has.

class Person {
    name: string
}

// We didn't use the "new" keyword
const person: Person = {
   name: 'Jame'
}

That wouldn't be possible in nominal type systems.

Let's see a slightly harder example:

type File = {
    name: string
    extension: string
}

type Folder = {
    name: string
    color: string
}

type DesktopItem = File | Folder

DesktopItem contains all the objects that either have the properties (name and type) of File or Folder.

const item: DesktopItem = couldBeFileOrFolder

// should work, right?
givenItem.extension

It doesn't work because only File has that property and the specific type of item could be Folder.

When we declare the union of two types the result is a type that has the intersection of the properties. In this case objects with a property name of type string, because it is the only property that they have in common.

It's also true the other way around: The intersection of two types results in a type that has the union of the properties.

keyof (A&B) = (keyof A) | (keyof B)
keyof (A|B) = (keyof A) & (keyof B)

The empty set and the universal set

If we can think of types as sets of values, what types are the empty set and the universal set?

never is the empty set and unknown is the universal set.

These are both very special and we'll talk about them soon.

Things to remember

Types are sets of values
One value of type Y is assignable to a type X if Y is a subtype of X.
Type compatibility in TypeScript is determined by structural typing.

Resources to go deeper

The known unknowns and learning on demand

Alex Menor — Fri, 11 Dec 2020 19:10:34 +0000

At the moment you put a feet in the cold water of software development, it's likely you scream and back away. You are probably overwhelmed with what it seems a forest of buzzwords.

While it's true that it's a big and fast evolving field, there are ways to benefit from that, and the how, it's what I want to talk about today.

The knowns and the unknowns

We can classify everything in:

Known knowns: The things we know we know. For a newbie programmer might be to write a little script in python that reverses the input.
Known unknowns: The things we know we don't know. For the same young programmer as before, may be send data over a network. He knows it can be done, he just doesn't know exactly how yet.
Unknown unknowns: The things we don't know we don't know.

The first category is vital because it enables us to immediately solve real world problems.

But I think that the second category is underrated. The known unknowns have a very low entry fee and it enables us to learn something on demand in order to solve a problem.

Why invest time in the known unknowns

I wish I got everything in the first category, but it's just impossible. Things keep evolving no matter what, there are simply too many things and it's costly in time to learn it all.

What is possible though, is to have a broad second category, that is: Have lots of known unknowns.

It has a very high value for the time it costs and you are probably not going to need to know all of it anyway.

For example: I never had to implement an event driven architecture, but I am familiar enough with the concept and its use cases.

Don't get me wrong, the devil is in the details and I would have to invest an important amount of time to learn how to implement it, but knowing that exists and what problems solves makes you a better developer already.

Takeaways

The software development field is too big, it's impossible to know every framework, tool or language that exists.
But that's okay, just start making a breadth-first search: Take a look at some roadmaps for example.
If you encounter any concept you don't know, spend 5 minutes reading about it and how could be useful to you in the future.
When a perfect use case comes for something you know that you don't know, invest time to learn it.
Learn something this way is easier, because there is a real reason behind.

Photo by 胡卓亨

Is "fundamentals first" the best approach to learning web development?

Alex Menor — Thu, 20 Aug 2020 16:27:34 +0000

A bit more than a year ago I started learning web development. Coming from a Computer Science background, where the I/O with computers is usually based on a terminal, they were exciting times.

So I started focusing on fundamentals as most people recommended: HTML, CSS and Javascript.

As I was doing this in my free time while also studying my degree I got exhausted by the time I got to Javascript and had to put it down for a while.

When I picked it up again, I progressed much faster through Javascript and started learning React. It was like unlocking a tool I could got creative with. I started enjoying coding.

Now with some perspective, I wonder what would have happened if I had started the other way around. Actually, a thread from Dan Abramov got me wondering.

Apparently this needs to be said but you can absolutely start with React and skip “JS fundamentals” IF YOU WANT. You’ll be confused about some things for sure (!), but for some people (incl. me) getting something on the screen is the only thing sustaining the initial interest

My past self would have argued the same, you would get confused about many things along the way, and while it's true, he makes a good point:

People keep answering: “but they will be confused”. YES they will be confused. The goal is not to eliminate confusion from the learning process, it is to not to lose people who give up because what they’re learning feels too far from what they want to be doing (make an app).

I even got confused going through fundamentals first. Specially with CSS. I remembered the moment I understood where flexbox was useful, like six months after "learning" it.

You are not going to see the importance of advanced topics of JS and CSS in the beginning, while is a totally worthy effort, you understand why much later.

The point I want to make is that while it's good for you to master the fundamentals, you realize it much later, which can discourage you to keep learning.

Note I didn’t say you never need to go lower level. You do — you will get stuck otherwise. And after you learn it, you’ll be convinced you “should have” learned that thing first, because you have an emotional understanding of why it mattered now.

And this is the most important thing for me: You should master fundamentals, that is no deal. The question is when.

Some people hold that should be in the beginning, perhaps biased by the former point.

I personally feel that you can set three phases:

Get the basics of HTML, CSS and Javascript right. Don't get burned out.
Pick up a framework, but keep in mind that you have some gaps to fill later on.
Master the basics on demand as you make projects.

You get a motivation boost in phase 1 because you are starting, in phase 2 because you are finally more powerful than before and in phase 3 as you progress doing and getting your hands dirty.

Finally, this is just my opinion. The most important thing is that you keep learning and feeling motivated to do so.

This is the thread I was talking about, thanks for reading 👋🏻.

The GitHub Student Pack free resources that you shouldn't miss

Alex Menor — Sat, 02 May 2020 18:51:37 +0000

Since 2014, GitHub have been providing students with free access to some tools that enable them to practice in a real world environment. In the moment I'm writing this, there are 107 different offers that you can take advantage of. I've been able to try several of them in the past year. Which of them are worth the most?

Heroku's free two year dyno

I'm very glad I started messing around with deployments of code and Heroku was a perfect introduction to the matter. Heroku is a Platform as a service that allows you to deploy any server side code such as Node, Ruby or Python from a Git repository, abstracting you from the infrastructure details.

Heroku offers a free plan dyno: It sleeps after 30 minutes without receiving any request and has limited CPU and memory resources.
With the GitHub Student Pack offer we got up to 2 years of a free hobby plan, which never sleeps and includes SSL.

Thanks to this, is very easy to host a side project in the cloud with no infrastructure costs for a while.

Infrastructure as a service with Digital Ocean and Azure

Once I was confident with Heroku IaaS such as AWS got my attention. Sadly you can't find Amazon Web Service between the resources provided by this pack, though, you have other alternatives.

Azure

Although the IaaS by Microsoft doesn't lack any of the products that you would expect, I didn't find it very beginner friendly at all (so isn't AWS) and I personally struggled to get the code deployments done or to setup a NoSQL database. When I finally could get everything up and running I realized that I had wasted the 100$ free Azure credits somehow.

Digital Ocean

Even though I've read bad things about this service I found it very straightforward and powerful on demand. It's storage uses the AWS S3 Bucket API (which makes things easier if you want to migrate later to the Amazon platform) and I learnt to setup a Docker Swarm thanks to its Doplets.

You can get 50$ in credits for Digital Ocean, and even though it's half the offer of Azure, they lasted me much longer.

Free domain: Namecheap, name.com and .tech

A landing page is something that many developers have and a chance to show the world some of your projects or to stand out between candidates for a job offer.

I tried these three providers but I could only made the student offer work with the later.

You get one .tech domain free for 1 year, I registered alexmenor.tech and had no issues yet.

Get into CI/CD with Travis

Last but not least, learning about code tests and continuous integration/deployment have been a game changer for me. Developing with testing in mind is very beneficial (that's going to be another post) and Travis allows you to test all your code after any push to your repo (between other many things).

Normally, you can setup Travis for free in any public repository. With this offer you can also use it within private ones while you are a student.

As you know, you learn a lot by getting your hands dirty and I recommend you to take advantage of all this resources to do it with professional tools.

To get any of this, you just have to confirm your school email in GitHub.

DEV Community: Alex Menor

Do you really know TypeScript? (4): Type assertions

What do you use type assertions for?

Golden rule for using assertions

Prefer type declarations to type assertions

Is as const a type assertion?

Don't type everything!

Don’t use uppercase variants of primitive types

Resources to go deeper

Do you really know TypeScript? (3): Types and interfaces

type can be used for more things

Interface merging

Discriminated union

Union of types vs types of unions

Excess property checking

Should I use type or interface then?

Resources to go deeper

Do you really know TypeScript? (2): Being strict

Strict settings

Handling type edge cases

The universal set

The empty set

Things to remember:

Resources to go deeper

Do you really know TypeScript? (1): Thinking in sets

Seeing types as sets of values

Structural typing

The empty set and the universal set

Things to remember

Resources to go deeper

The known unknowns and learning on demand

The knowns and the unknowns

Why invest time in the known unknowns

Takeaways

Is "fundamentals first" the best approach to learning web development?

The GitHub Student Pack free resources that you shouldn't miss

Heroku's free two year dyno

Infrastructure as a service with Digital Ocean and Azure

Azure

Digital Ocean

Free domain: Namecheap, name.com and .tech

Get into CI/CD with Travis

Is `as const` a type assertion?

`type` can be used for more things

Should I use `type` or `interface` then?