DEV Community: Vladyslav

Deep dive into TypeScript Utility Types. Part 1

Vladyslav — Wed, 20 Jul 2022 15:41:06 +0000

If you are using TypeScript on an everyday basis or just getting familiar with it, you might have heard about its utility types. Utility types are the built-in types that you can use as a developer without needing any additional packages. Most of the time we don't ponder about how those types are designed under the hood and just use them according to TypeScript Documentation. Don't take me wrong, there is nothing bad with that, especially considering that TypeScript is managed by Microsoft and there is a bunch of smart people responsible for it. But to better understand how utility types work, there is a better approach - to implement them on your own.

So, let's dive deep into it and try to implement custom utility types.

Partial

The first type we'll discuss today is Partial<T>. According to documentation:

Partial<T> constructs a type with all properties of T set to optional and returns a type that represents all subsets of a given type.

Before implementing any of the TypeScript Utility types there is one important thing we should discuss - Mapped types. In short, Mapped types build on the syntax for index signatures, which are used to declare the types of properties which has not been declared ahead of time. Okay, less talking more coding.

So, what is going on in the example above? The first and foremost thing to understand is that by using mapped types we just simply iterating all properties of type T that is passed as a generic argument to our custom partial type. But iterating is not just enough since partial means that all the properties should be optional. To do so, we use mapping modifiers, more specifically ?, which serves as optionality modifier.

Required

The next utility type we'll take a look at today is Required<T>. In general, it is simply opposite to Partial<T> that accepts as generic argument some object of type T and makes all of its properties required. To remove optionality modifier we simply prefix it with -.

Readonly

Readonly<T> is yet another utility type that is immensely easy to implement. In this case, everything that is needed to make all properties of T immutable is to add readonly mapping modifier.

Record

So far, we've been talking about simple types that cause no problem to implement. On contrary, Record<K, T> is a little bit different and is designed to construct an object of specific structure - to accept only certain types of values as its property keys and property values. The custom implementation of Record<K, T> would look something like this:

Since the user is responsible for providing us with valid types that should be keys (K) instead of iterating all keys in T as we did in Partial<T>, Required<T> and Readonly<T> we simply iterate through all properties in K - P in K. Another thing worth our attention for better understanding is K extends number | string | symbol. Since our custom record type is an object and as we know javascript object accepts as key values only string, number or symbol by typing K extends number | string | symbol we just manually telling that our MyRecord<K, T> should follow this rule as well.

Final words

Thanks for reading the first part of the "Deep dive into TypeScript Utility Types" series. Hope it will throw light on TypeScript Utility types and help to understand how they are implemented. Next time, we will discuss other types as Pick<Type, Keys>, Omit<Type, Keys>, ReturnType<Type>, and much more.

Keep in touch and happy coding.

Why I moved to TypeScript and have no regrets

Vladyslav — Wed, 15 Jul 2020 13:45:09 +0000

It‘s worth being said that it wasn’t my intention to move to TypeScript instead of vanilla JS. It just happened that we decided to move our production-ready project to Angular 4, which, as all of you know, uses TypeScript as a default language. Despite the fact that Angular projects can also be written in plain JavaScript, it’s documentation, examples, and most of the answers at StackOverflow are written in TypeScript. So, the decision was made and I have no single regret of doing that. Let me explain why.
TypeScript provides us with a bunch of advantages that are not implemented in ECMAScript aka JavaScript yet. So, let’s discuss them one by one.

Types

For those of you who didn’t work or hear about TypeScript:

…it is a typed superset of JavaScript that compiles to plain JavaScript

It becomes obvious from the language name that the main difference lies in the fact that TS uses types. So, yeah, it is strongly typed language, the feature that about 50% of JavaScript developers were missing and the remaining 50% hate in other strongly-typed languages. Without referring types of responses or other data, we had a lot of freedom in our code but at the same time this freedom is the main reason for lots of errors that are hardly debuggable (not sure if such a word even exists).
From my perspective, types are great. They make your code more accurate and understandable for other developers. It makes much easier to see what method returns when you intentionality define its return type and it also prevents you from returning something else. The second benefit of typing is to see the response type of your Http request. We all know how painful it may be in JavaScript to debug errors when your code doesn’t work properly and the reason for that is that you’re referring to a response property which may not exist at all. Therefore, declaring response type prevents you, a developer, from this headache.

Classes and Interfaces

For those of you who gonna tell me that ES6 introduced classes, my response would be “Yes, I know that”. However, typescript is not just about classes and types. If not mentioning that TS classes also provide us, developers, with public, private, static, readonly members of classes, it also introduces to us Abstract Classes and Interfaces, which we do not currently have in JavaScript.
Abstract Classes are a part of more advanced topics of OOP rather than TypeScript but still, they are worth mentioning. Here’s a quote from the official TS documentation:

Abstract classes are base classes from which other classes may be derived. They may not be instantiated directly. Unlike an interface, an abstract class may contain implementation details for its members. The abstract keyword is used to define abstract classes as well as abstract methods within an abstract class.

The simplest and the most vivid example of Abstract Class is:

abstract class Animal { 
   abstract makeSound(): void; 
   move(): void { 
      console.log(“roaming the earth…”); 
   } 
}

Interfaces are another great feature that was introduced in TypeScript and which is actually used on a daily basis compared to Abstract Classes. Generally, in Typescript, interfaces fill the role of naming your own data types, and are considered a powerful way of defining contracts within your code as well as contracts with code outside of your project. It means that interface helps you define the skeleton of classes or data types, while their actual implementation may differ.

Public, Private, Protected, Static, Readonly Modifiers

As it’s been mentioned before, ES6 introduced classes to JavaScript developers, but it missed one important thing — modifiers. Since TypeScript is a more advanced and progressive version of JavaScript, it successfully fills this gap. With such modifiers as public, private, protected, static, readonly, we are able to enclose variables, properties, and methods into the corresponding scope. Plus, it is no longer needed to use different workarounds like IIFE or revealing patterns. With TypeScript, you can easily define which fields and methods should be accessible outside classes and which should not, which ones we allow to change and which should always remain unchanged.

Namespaces and Modules

Comparing to ES6, which has modules to help developers organize their code, TypeScript also gives them such a nice thing as namespaces that are heavily used in other OOP languages like C#.
Briefly speaking, namespaces are a way of organizing code, dividing it into different parts, which gives us an access to the code from the other parts of an application.
Using namespaces is especially useful when you do not want to spoil the global scope with a bunch of variables. Apart from that, interfaces are very handy when the application is quite big and we want to split the code across multiple files to make it easier to maintain in the future.

TypeScript Is Still JavaScript

The last but not least thing I’d like to mention is that TypeScript is still JavaScript. TS is based on ES6 features and does not provide new methods or change the existing ones. If you compile your TS code into JavaScript, you will see the same Prototypical Inheritance. You will never see in a compiled JS code interfaces, decorators, modifiers — they just do not exist. Therefore, it is just a layer on top of JavaScript, which improves the experience of developers and prevents lots of unnecessary bugs from happening.
On top of that, you are free to choose to which version of JavaScript your TypeScript code will be compiled, which means it will run even in Internet Explorer.
Don’t take me wrong, I am not telling that we all should stop writing in JavaScript and move to TypeScript. JavaScript is a great language with an increasing pace of development. Its popularity is growing from year to year and now it is one of the most popular and frequently used programming languages. Still, there are a lot of areas for future improvements, and that’s where TypeScript comes into play.