Forem: Tomohiro Yoshida

Three Ways of Using "extends" in TypeScript

Tomohiro Yoshida — Tue, 20 Jun 2023 06:25:32 +0000

When writing a TypeScript code, you will often see the "extends" keyword. But please be careful! This keyword works differently according to its context.
In this article, I am going to explain how to use "extends" in three different ways in TypeScript.

1. Inheritance

The "extends keyword" will be used for Interface Inheritance (or Class Inheritance). Here is an example of the Interface Inheritance:

interface Vehicle {
    wheels: number;
    maker?: string;
}

interface Car extends Vehicle {
    power: "gas" | "electricity";
}

interface Bicycle extends Vehicle {
    folding: boolean;
}

const myCar: Car = {
    wheels: 4,
    maker: "Toyota",
    power: "gas"
} // OK

const car: Car = {
    wheels: 4,
    maker: "Honda",
    power: "gas",
    folding: false
} // Error
// Type '{ wheels: number; maker: string; power: "gas"; folding: boolean; }' is not assignable to type 'Car'.
    // Object literal may only specify known properties, and 'folding' does not exist in type 'Car'.

const bicycle: Bicycle = {
    wheels: 2,
} // Error
// Property 'folding' is missing in type '{ wheels: number; }' but required in type 'Bicycle'.

You can make an inherited interface from a base interface. (In this example, Vehicle is the base interface, and Car and Bicycle are the inherited interfaces.)
If you want to make a new interface taking over properties from other interfaces, this technique is useful because you do not have to declare a new interface from scratch again.
(I discussed Interface Extensions and Merging in detail in another article, so please read this one if you want to know more about it.)

2. Generic Constraints

If you are an intermediate or advanced TypeScript programmer, you may want to use Generic Types in your code. For example, if you want to get the value from an object's property, you may write the code below:

const testObj = { x: 10, y: "Hello", z: true };

function getProperty<T>(obj: T, key: keyof T) {
  return obj[key];
}

const xValue = getProperty(testObj, 'x');
const yValue = getProperty(testObj, 'y');

The above code is functional. But this is not type safe enough. Let me hover my cursor over xValue and yValue and see their types.

const xValue = getProperty(testObj, 'x');
// const xValue: string | number | boolean

const yValue = getProperty(testObj, 'y');
// const yValue: string | number | boolean

You might expect the type of xValue would be number and the one of yValue would be string. However, unfortunately, the TypeScript type system could not narrow down the returned type of the getProperty function. As a result, the type of the return value of the function has become a union type of the testObj properties.
If you want to make a more type-safe function, you should use a technique, Generic Constraints, and narrow down the type of the return value. Let me refactor the previous example code:

const testObj = { x: 10, y: "Hello", z: true };

function getProperty<T, K extends keyof T>(obj: T, key: K) {
  return obj[key];
}

const xValue = getProperty(testObj, 'x');
// const xValue: number
const yValue = getProperty(testObj, 'y');
// const yValue: string

As you saw, the types of xValue and yValue are narrowed down to a certain type of the testObj's properties.
In the above example code, the extends keyword works to constrain the type of the generic, K. In other words, one of the keys of T is chosen for K instead of allowing any keys to be the type of the key argument. Thus, the function can be limited to only one return type instead of a union type.

3. Conditional Types

TypeScript has the capability of making a logic to dynamically generate a type according to a type assigned to a generic.
Here is an example:

type IsString<T> = T extends string ? true : false;

type x = IsString<'hello'>;
// type x = true

type y = IsString<number>;
// type y = false

type z = IsString<string>;
// type z = true

The IsString type is the so-called Conditional Type. The type of IsString differs according to its generic, T.
Let me interpret the line, T extends string ? true : false;.
If the type of T(left) is a subtype of string(right), in other words, if the T(left) type is assignable to the string(right) type, it returns true. Otherwise, it will be false.

Conclusion

In conclusion, the extends keyword in TypeScript is a versatile tool, playing crucial roles in interface inheritance, generic constraints, and conditional types. Mastering these concepts will help you write cleaner, more robust and more flexible TypeScript code.
However, at the same time, this keyword may confuse you when reading a codebase written by other developers since the extends keyword works differently according to contexts.
Therefore, you should keep in your mind the fact that the keyword has several meanings, "Inheritance", "Generic Constraints", and "Conditional Types".

What is call, apply, and bind in JavaScript?

Tomohiro Yoshida — Fri, 02 Jun 2023 02:18:55 +0000

Do you know how to use Function.call(), Function.apply(), and Function.bind()?

These methods are used to control what the this keyword refers to in a function.

Function.call()

The call() method is explained in MDN below:

The call() method calls the function with a given this value and arguments provided individually.

The syntax of the method is:

call(thisArg)
call(thisArg, arg1)
call(thisArg, arg1, /* …, */ argN)

Here is an example code to see what this refers to without call().

const message = "Hello from window!";

function test() {
    console.log(this.message);
};

test();
// [LOG] Hello from window!

If we do not use call(), this in the test function refers to the global window object. Therefore, the console.log() in the function displays the message, "Hello from window!".

Note: If it was an object method, this refers to the object.

Next, let's see what happens when using call().

const message = "Hello from window!";

const testObj = {
  message: "Hello from testObj!"
};

function test() {
    console.log(this.message);
};

test.call(testObj);
// [LOG] Hello from testObj!

As you can see, this refers to the testObj object when we execute the test function by the call() method with the argument of testObj. It means the this keyword in the function considers testObj as this.

What if the function requires arguments?

If a function requires arguments, you can execute the function with arguments like below:

const testObj = {
  message: "Hello from testObj!"
}

function test(arg1, arg2, arg3) {
  console.log(this.message);
  console.log("arg1: ", arg1, " arg2: ", arg2, " arg3: ", arg3);
}

test.call(testObj, 1, 2, 3);
// [LOG] Hello from testObj!
// [LOG] arg1: 1 arg2: 2 arg3: 3

Function.apply()

The apply() method works similarly to the call() method. But the only difference is the apply() method receives an array of the original function's arguments as an argument.

The syntax of the method is:

apply(thisArg)
apply(thisArg, argsArray)

If you want to execute the test function by the apply() method, the code will be like this:

const testObj = {
  message: "Hello from testObj!"
}

function test(arg1, arg2, arg3) {
  console.log(this.message);
  console.log("arg1: ", arg1, " arg2: ", arg2, " arg3: ", arg3);
}

test.apply(testObj, [1, 2, 3]);
// [LOG] Hello from testObj!
// [LOG] arg1: 1 arg2: 2 arg3: 3

Cool! We can get the same outcome as the previous example code.

Function.bind()

The bind() method works differently compared with the other two methods.
This method returns a copy of the function with provided arguments instead of executing the function immediately.

The syntax of the method is:

bind(thisArg)
bind(thisArg, arg1)
bind(thisArg, arg1, arg2)
bind(thisArg, arg1, arg2, /* …, */ argN)

As with the call() method, the bind() method will receive a value that will be a target of this and a number of arguments that will be provided to the original function.

If you want to use the bind() method with the test function, which we used above, the code will be below:

const testObj = {
  message: "Hello from testObj!"
}

function test(arg1, arg2, arg3) {
  console.log(this.message);
  console.log("arg1: ", arg1, " arg2: ", arg2, " arg3: ", arg3);
}

const boundTestFunc = test.bind(testObj, 1, 2, 3);

boundTestFunc();
// [LOG] Hello from testObj!
// [LOG] arg1: 1 arg2: 2 arg3: 3

As you saw, we could get the same log results as the call() method. However, you need to execute the new function after making a copy of the original one, like boundTestFunc() if you want to call it.

What is the actual use case?

You may wonder when we use the methods in real-world development. I would honestly say that we do not frequently use these methods on a daily basis.
But, let me share one of the common use cases of the bind() method in modern web development.

You will see a code like the one below if you are assigned to work on refactoring the React.js project written with the Class components.

class ExampleComponent extends React.Component {
  constructor(props) {
    super(props);
    this.state = { value: '' };
  }

  handleChange(event) {
    this.setState({value: event.target.value});
  }

  render() {
    return (
      <input
        type="text"
        value={this.state.value}
        onChange={this.handleChange.bind(this)}
      />
    );
  }
}

The bind() method is used when passing the handleChange method to onChange of the input element. This is because when calling the method as an event handler in Class components of React.js, this will be undefined. (this should have referred to the object if the this keyword is used in methods of the object.)

But, considering recent React.js projects, Functional components are used more often than Class components. Thus, you rarely see Class components and the bind() method accordingly, even in React.js projects, unless you are assigned to legacy code maintenance or refactoring.

Summary

The three methods, Function.call(), Function.apply(), and Function.bind(), are used to control where the this keyword refers to.
The call() and apply() methods are used to immediately execute a function with a certain this and arguments. These are used for very similar purposes.
On the other hand, the bind() method is used to create a new function, and that was commonly used in Class components in React.js project.

What are global types/interfaces in TypeScript?

Tomohiro Yoshida — Tue, 09 May 2023 03:03:16 +0000

Do you know what global types/interfaces are?
In TypeScript, we can use types/interfaces declared in module files by importing and exporting them. However, in addition to that, we can use types/interfaces floating around in the TypeScript type system.

Global Objects

When you hover a cursor over the window object, you can see the type below:



var window: Window & typeof globalThis

As you can see, the type (interface) of the window object is Window. You will be able to observe the type even though you have never declared the type. So what is going on behind the scene?
If you are working on a project with TypeScript, please dive into the node_module package of typescript. You will be able to find the Window interface declaration in lib.dom.d.ts like the image below:

TypeScript prepares the global types/interfaces for the global objects such as window and localStorage. Thanks to that, we can use the types of these global objects without our own declaration.

Declare Global Types/Interfaces

If you want to declare types/interfaces globally, it is possible to do that using some techniques. Let me explain how to do it.

Make 'scripts' instead of 'modules'

In TypeScript and modern JavaScript projects, using modules rather than scripts is generally recommended because modules are easier to maintain. But we can take advantage of the global scripts to make global types/interfaces. If you want to make a script file, do not use any import or export keywords in the file. As long as you do not use the keywords, the file is treated as a script file by TypeScript, and types/interfaces in the file are accessible in the global scope.

'declare global block'

You can even declare global types/interfaces within the declare global block in the module file. Here is an example:



export type ThisIsAType = string;

declare global {
  type ThisIsAGlobalType = string;
}

If you want to use ThisIsAType in a different file, you have to import it. On the other hand, you do not have to import ThisIsAGlobalType wherever you want to use it in your project because it is floating in the global scope.

Example in the Real-Scenario

As you know, there are several objects you can access in the global scope. This time, I will give you one example of utilizing this technique for environment variables in a React.js project.

When you want to use environment variables in React.js, you will make a .env file in the project's root and access the env vars using the process.env. The code will be like below:



// .env
REACT_APP_API_KEY=1234567890abcdef
REACT_APP_API_URL=https://api.example.com



// App.tsx
function App() {
  const apiKey = process.env.REACT_APP_API_KEY;
  const apiUrl = process.env.REACT_APP_API_URL;

  return (
    <div>
      <p>API key: {apiKey}</p>
      <p>API URL: {apiUrl}</p>
    </div>
  );
}

export default App;

Output on the screen

It works with this minimum setup though we can not use an autocomplete feature of the IDE. I mean, even if you type process.env., you can not find REACT_APP_API_KEY and REACT_APP_API_URL in a suggestion, like an image below:

If there are a lot of env vars, you may make a typo of the env vars' names. To reduce the risk of typos or something, it may be good to merge your custom interface to add properties to the ProcessEnv interface by using the global scope declaration. Here is an example:



// types.d.ts
declare global {
  namespace NodeJS {
    interface ProcessEnv {
      REACT_APP_API_KEY: string | undefined;
      REACT_APP_API_URL: string | undefined;
    }
  }
}

export {};

After making the type declaration file and writing the code above, you can find your env vars' names, REACT_APP_API_KEY and REACT_APP_API_URL, in a suggestion.

Perfect! We could add the custom properties to the ProcessEnv interface.

Note 1: A namespace is a way to group related code and prevent naming collisions. This may be helpful when you are working on a large-scale project or making a node_module. You can find more info in the official doc.

Note 2: The TypeScript type system cannot warn you even when trying to access a property (environment variable) that does not exist in process.env because the ProcessEnv interface has an index signature. Please refer to the official doc if you are not familiar with it.

Conclusion

TypeScript's global types and interfaces allow seamless access to global objects like window and localStorage. Declaring global types can be done by creating 'scripts' or using the 'declare global' block. These techniques enhance the developer experience, such as providing autocompletion suggestions for environment variables.
Overall, global types and interfaces in TypeScript contribute to more maintainable code and an improved developer experience.

You must know how to use Generics of Promises in TypeScript

Tomohiro Yoshida — Thu, 27 Apr 2023 09:14:02 +0000

Generics is one of the most difficult parts for TypeScript learners. However, you can not avoid studying it because you must use Generics whenever you use Promises in your code.
It's hard to make any websites or web apps without Promises. Therefore, it is a good time to learn how to use Generics of Promises if you are unfamiliar with it!

Creating Promise with the Promise class

First, create a simple Promise that returns the "message" object.

const simplePromise = new Promise((resolve) => {
    resolve({message: 'success!'});
});

Next, execute this promise to see the result.

(async() => {
    const result = await simplePromise;
    console.log(result.message);
})();

A success message is displayed on the console.
Okay, this code can just work. But there is a problem. Let's take a look into the type error message.

(async() => {
    const result = await simplePromise;
    // Type -> const result: unknown
    console.log(result.message);
    // Type error -> 'result' is of type 'unknown'.
})();

Since we did not provide a type argument to the Promise class, the type of the Promise was Promise<unknown>. That is why the type checker could not predict the type of the value given by resolve. As a result, it became unknown and the type error occurred when accessing a message property.
It's very troublesome if we leave the return value as unknown. Therefore, we need to provide a type argument when creating a new Promise. Here is an updated code:

const simplePromise = new Promise<{message: string}>((resolve) => {
    resolve({message: 'success!'});
});

(async() => {
    const result = await simplePromise;
    // Type -> const result: { message: string; }
    console.log(result.message);
    // OK
})();

Perfect! In this example code, the type checker could successfully predict the type of the result variable.

Async Functions

The type of a returned value from an async function also will be a Promise. Thus, we have to be more aware of type arguments and type annotations when working on async functions.
To examine the type of a returned value from async functions, let's make a simple fetch function and call it.

async function getRandomCatFact() {
  const response = await fetch('https://catfact.ninja/fact');
  return response.json();
}

(async() => {
    const cat = await getRandomCatFact();
    console.log(cat.fact);
})();
// [LOG]: "At 4 weeks, it is important to play with kittens so that they do not develope a fear of people."

Okay, this code worked and displayed the interesting fact about cats on the console. But, if it works, what's wrong?
Let's take a look at the types of the returned value.

async function getRandomCatFact() {
  const response = await fetch('https://catfact.ninja/fact');
  return response.json();
}
// Type -> function getRandomCatFact(): Promise<any>

(async() => {
    const cat = await getRandomCatFact();
    // Type -> const cat: any
    console.log(cat.fact);
})();

Since no type argument was provided, the type of the return value from the function became Promise<any>. Thus, the type of the cat variable also became any. So, this code has a potential risk of a runtime error if a developer makes a typo like below:

console.log(cat.typo);

The type checker cannot catch even such a silly typo if the type of the variable is any.
To solve the issue, we have to update the function so that we can pass a proper type to it. Before doing it, let's declare an interface for the API response.

interface CatFact {
  fact: string;
  length: number;
}

And then, update the function.

async function getRandomCatFact(): Promise<CatFact> {
  const response = await fetch('https://catfact.ninja/fact');
  return response.json();
}

Thanks to the type annotation, the TypeScript type checker knows what type of value will be returned from this function. Therefore, we can see a type error if we make a typo like below:

(async() => {
    const cat = await getRandomCatFact();
    console.log(cat.typo);
    // Type error -> Property 'typo' does not exist on type 'CatFact'.
})();

Perfect! Now, you can use Promise and Async properly in your TypeScript project.

Conclusion

In conclusion, understanding and implementing Generics with Promises is vital for TypeScript learners, as they are crucial in web development. By providing type arguments in Promises and using type annotations in async functions, developers can improve code quality, minimize runtime errors, and benefit from the type checker's ability to catch potential issues, ensuring a stable and reliable TypeScript project.

Assertions in TypeScript

Tomohiro Yoshida — Sun, 23 Apr 2023 22:56:43 +0000

In TypeScript, there is a technique that is so-called Assertions.
Generally, it is better to avoid using assertion because it forces the TypeScript type system to write its type over. However, there are some situations it is reasonable to use assertion to make your code work as you expect. In this article, I will share assertions and how to use assertions in your project.

Type Assertions

When you use certain methods, it may return something that you did not expect. Here is an example.

const originalArray = ["hello", "world"];
// const originalArray: string[]

const jsonString = JSON.stringify(originalArray);
// const jsonString: string

const parsedArray = JSON.parse(jsonString);
// const parsedArray: any

console.log(parsedArray);
// [LOG]: ["hello", "world"]

In this example, the type of parsedArray becomes any though we can retrieve the data we want. This is a good use case of type assertion because the JSON.parse method always returns any.

(method) JSON.parse(text: string, reviver?: ((this: any, key: string, value: any) => any) | undefined): any

That is why, we will have to use assertion to notify the TypeScript type system of the actual type of the returned value. Here is an updated code.

const originalArray = ["hello", "world"];
// const originalArray: string[]

const jsonString = JSON.stringify(originalArray);
// const jsonString: string

const parsedArray = JSON.parse(jsonString) as string[];
// const parsedArray: any

console.log(parsedArray);
// [LOG]: ["hello", "world"]

Perfect! You can avoid unexpected runtime errors by using assertions properly
Let me give you another example.

const element = document.getElementById('myElement');

console.log(element.innerText);
// type error: 'element' is possibly 'null'.

In this above example, you will encounter the type error, "'element' is possibly 'null'.". That is because document.getElementById returns union type, HTMLElement | null. Therefore, it will be good to cast the HTMLElement type if you are 100% sure that it is not null.

const element = document.getElementById('myElement') as HTMLElement;
console.log(element.innerText); // OK

Please note that type assertion is not the only solution in this scenario. You may be able to use type guard instead like below:

const element = document.getElementById('myElement');

if (element) {
  console.log(element.innerText); // OK
}

Non-Null Assertions

Speaking of the document.getElementById method, you may be able to use Non-null assertion if it is enough to tell the TypeScript type checker that the type of the returned value is NOT null.
By adding a ! instead of as type, you can just notify the type checker that the returned value will never be null. Here is an example:

const element = document.getElementById('myElement')!;

console.log(element.innerText); // OK

Const Assertions

Finally, let me introduce const assertions that work differently from other assertions.
When you use the const assertions, values affected by the const assertion will freeze.
For example, if a value is Array, it will be a readonly tuple that is an immutable array. If a value is Number or String, the type of the value becomes literal instead of the general primitive. If you use it for an object, the properties of the object will be readonly.
Here is an example:

// Readonly tuple (immutable array)
const coordinates = [1, 2, 3] as const;
// coordinates: readonly [1, 2, 3]

// The following line will cause a TypeScript error because
// the array is now a readonly tuple and cannot be modified.
// coordinates[0] = 5;

// Literal types
const age = 30 as const;
// age: 30

// The following line will cause a TypeScript error because
// age is now a literal type and cannot be assigned a new value.
// age = 31;

const student = "John" as const;
// student: "John"

// The following line will cause a TypeScript error because
// him is now a literal type and cannot be assigned a new value.
// student = "Jane";

// Readonly properties for objects
const person = {
  firstName: "Alice",
  lastName: "Smith",
} as const;
// person: { readonly firstName: "Alice"; readonly lastName: "Smith" }

// The following line will cause a TypeScript error because
// person.firstName is now a readonly property and cannot be modified.
// person.firstName = "Bob";

In this example, I have used const assertions to create readonly tuples, literal types, and readonly properties for objects. Notice how trying to modify these values causes TypeScript errors, since const assertions make them immutable.

Conclusion

In conclusion, TypeScript assertions are a powerful tool for handling specific cases where type inference falls short or additional type information is required. They include type assertions, non-null assertions, and const assertions. While they can help prevent runtime errors and improve code readability, they must be used carefully. Using too many assertions can lead to potential runtime issues if used incorrectly. Always prioritize TypeScript's type inference and type-checking mechanisms, resorting to assertions only when necessary to ensure a robust and maintainable codebase.

Type Operators (keyof and typeof) in TypeScript

Tomohiro Yoshida — Sun, 16 Apr 2023 12:06:30 +0000

Have you ever heard typeof operator?
I guess 99% of readers will say "yes".
However, do you really understand the difference of typeof between in TypeScript and JavaScript?
If you are not confident, no worries! This article is for you!
I am going to explain how to use Type Operators, keyof and typeof, in this article.

Type Operators

keyof operator

You may sometimes be tired of writing types. For example, here is an example:

const createPerson = (id: number, name: string, age: number) => {
  return {
    id,
    name,
    age
  };
};

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

const showPersonsProperty = (person: Person, key: "id" | "name" | "age") => {
  console.log("This person's " + key + " is " + person[key] + ".")
};

const person1 = createPerson(1234, "John", 20);

showPersonsProperty(person1, "name");
// [LOG]: "This person's name is John"

showPersonsProperty(person1, "age");
// [LOG]: "This person's age is 20."

The above code is functional. But how did you feel about this?

Actually, we can make this code more concise by utilizing type operators!

We (and TypeScript's type checker) already know the possible argument to be passed to the "key" parameter when defining the Person interface.

If so, why don't we use this Person interface to get its keys?
Let me show the updated code.

const createPerson = (id: number, name: string, age: number) => {
  return {
    id,
    name,
    age
  };
};

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

const showPersonsProperty = (person: Person, key: keyof Person) => {
  console.log("This person's " + key + " is " + person[key] + ".");
};

const person1 = createPerson(1234, "John", 20);

showPersonsProperty(person1, "name");
// [LOG]: "This person's name is John"

showPersonsProperty(person1, "age");
// [LOG]: "This person's age is 20."

In this updated code, we could refer to the keys of the Person interface instead of giving union type ("id" | "name" | "age") to the key parameter.
The keyof operator generates a union type from keys of Object Type (Interface). In the former example codes, "id" | "name" | "age" and keyof Person have the same meaning.
This technique will help your life when an object has tons of properties!

typeof operator

Next, what if a person object is declared manually, like the below code?

const person1 = {
  id: 4321,
  name: "Mike",
  age: 35
};

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

const showPersonsProperty = (person: Person, key: keyof Person) => {
  console.log("This person's " + key + " is " + person[key] + ".");
};

showPersonsProperty(person1, "name");
// [LOG]: "This person's name is Mike."

showPersonsProperty(person1, "age");
// [LOG]: "This person's age is 35."

Hmm... This code works okay. But we can write simpler code by utilizing typeof operator.
Here is an example.

const person1 = {
  id: 4321,
  name: "Mike",
  age: 35
};

const showPersonsProperty = (person: typeof person1, key: keyof typeof person1) => {
  console.log("This person's " + key + " is " + person[key] + ".");
};

showPersonsProperty(person1, "name");
// [LOG]: "This person's name is Mike."

showPersonsProperty(person1, "age");
// [LOG]: "This person's age is 35."

Perfect! We could skip defining the Person interface by referring to the person1 object.
You can use typeof to retrieve the type of a value. (Please keep in mind that this typeof is the operator provided by TypeScript. It means this operator does not exist in runtime.)

keyof typeof

You might wonder what is keyof typeof. Good question!
Let me explain this advanced technique.
By chaining these two operators, you can retrieve the keys of an object variable as Union type.

First, the Object type is retrieved by typeof objectVariable. Second, keys of the Object type are extracted by the keyof operator. Finally, these keys will be a literal union type.

By using the type operators, we will be able to write more concise code!

Interface Extensions/Merging in TypeScript

Tomohiro Yoshida — Tue, 28 Mar 2023 06:13:21 +0000

TypeScript has the capability of extending and merging interfaces.

Our development will be more efficient by utilizing these advanced features.

Basic Usage of Interfaces

Interfaces are similar to object-type aliases. Here is a comparison between an interface and an aliased object type.

type Vehicle = {
    wheels: number;
    maker: string;
};

interface Vehicle {
    wheels: number;
    maker: string;
}

This type and interface can be used in almost the same way.

In this article, I will dig deeper into the interface to introduce more advanced techniques.

Interface Extensions

You may notice that some interfaces sometimes look similar to each other when it comes to a big project. If some interfaces have common properties, it is a good time to extend one interface and make another one. Let me show an example:

interface Vehicle {
    wheels: number;
    maker?: string;
}

interface Car extends Vehicle {
    power: "gas" | "electricity";
}

interface Bicycle extends Vehicle {
    folding: boolean;
}

const myCar: Car = {
    wheels: 4,
    maker: "Toyota",
    power: "gas"
} // OK

const car: Car = {
    wheels: 4,
    maker: "Honda",
    power: "gas",
    folding: false
} // Error
// Type '{ wheels: number; maker: string; power: "gas"; folding: boolean; }' is not assignable to type 'Car'.
    // Object literal may only specify known properties, and 'folding' does not exist in type 'Car'.

const bicycle: Bicycle = {
    wheels: 2,
} // Error
// Property 'folding' is missing in type '{ wheels: number; }' but required in type 'Bicycle'.

Both Car and Bicycle interfaces have common properties, wheels (required) and a maker (optional). Therefore, they can derive these properties from the Vehicle interface.

Cool! You can avoid repetitive code by using this technique.

What If You Declare the Same Property in a Child Interface?

It is possible to declare the same name of the property again when making a descendant interface. However, it does not mean you can freely override the parent’s property. The rule is you can override a property as long as a new re-declared property is assignable to the parent one.

Here is an example:

interface Vehicle {
    wheels: number;
    maker?: string;
}

interface Car extends Vehicle {
    power: "gas" | "electricity";
}

interface ElectricCar extends Car {
    power: "electricity";
} // OK

interface FuturisticCar extends Car {
    power: "air";
} // Error
// Interface 'FuturisticCar' incorrectly extends interface 'Car'.
  // Types of property 'power' are incompatible.
    // Type '"air"' is not assignable to type '"gas" | "electricity"'.

As you can see above, "electricity" is assignable to the literal union type, "gas" | "electricity", because "electricity" is included in the union type. Thus, it’s possible to make ElectricCar by extending the Car interface.

On the other hand, the TypeScript type checker yells at you when making the FuturisticCar interface because "air" is not included in "gas" | "electricity”.

Interface Merging

In the previous section, I explained what happens when you declare the same property while extending another interface.

Next, guess what happens when you declare multiple interfaces with the same name.

interface Vehicle {
    wheels: number;
    maker?: string;
}

interface Vehicle {
    price: number;
}

const vehicle: Vehicle = {
    wheels: 4,
    maker: "Nissan",
    price: 25000
} // OK

const vehicle2: Vehicle = {
    maker: "Nissan",
    price: 25000
} // Error
// Property 'wheels' is missing in type '{ maker: string; price: number; }' but required in type 'Vehicle'.

const vehicle3: Vehicle = {
    wheels: 4,
    maker: "Nissan",
} // Error
// Property 'price' is missing in type '{ wheels: number; maker: string; }' but required in type 'Vehicle'.

In this example, Vehicle is declared twice. Since both interfaces have the same name, TypeScript merges them into one interface. As a result, the final Vehicle interface has wheels, maker, and price properties. Technically, it is the same as declaring one Vehicle interface with the three properties.

But what if those interfaces have the same property name with different types?

Let’s take a look at the example code below:

interface Vehicle {
    wheels: number;
    maker?: string;
    plate: number;
}

interface Vehicle {
    plate: string;
} // Error
// Subsequent property declarations must have the same type.  Property 'plate' must be of type 'number', but here has type 'string'.

It is not allowed to declare the same property with different types because it causes conflicts. The TypeScript type checker will warn that subsequent property declarations must have the same type.

Conclusion

Interface extensions allow developers to avoid repetitive code by deriving common properties from a parent interface.
When declaring the same property in a child interface, it is only allowed if the new re-declared property is assignable to the parent one.
Interface merging can be used to combine interfaces with the same name, but it is not allowed to declare the same property with different types as it causes conflicts.

Tuples in TypeScript

Tomohiro Yoshida — Sun, 19 Mar 2023 21:57:15 +0000

Do you know what Tuple is? If you are a JavaScript developer, I guess you are unfamiliar with this data type because there is no Tuple in JavaScript.

Tuple is a more strict version of Array, which can store only a static number of elements and types at each index.

Let me clarify the difference between Tuple and a simple Array and explain how to use it.

Type Declaration

Union-Type Array

When you want to use a simple union-type array, the syntax is as follows:

type UnionArrayType = (string | number)[];

let unionArray1: UnionArrayType;
unionArray1 = ["hello world", 1]; // OK

let unionArray2: UnionArrayType;
unionArray2 = [2, "hello world"]; // OK

let unionArray3: UnionArrayType;
unionArray3 = [3, "hello", "world"]; // OK

let unionArray4: UnionArrayType;
unionArray4 = [4, "hello", "world", true];
// Type 'boolean' is not assignable to type 'string | number'.

The array of UnionArrayType can accept any number of members as long as the types of elements are string or number.

Tuple

The syntax for Tuple is as follows:

type MyTupleType = [string, number];

let myTuple1: MyTupleType;
myTuple1 = ["hello world", 1]; // OK

let myTuple2: MyTupleType;
myTuple2 = [2, "hello world"];
// Type 'number' is not assignable to type 'string'.
// Type 'string' is not assignable to type 'number'.

let myTuple3: MyTupleType;
myTuple3 = ["hello world", 1, 2];
// Type '[string, number, number]' is not assignable to type 'MyTupleType'.
  // Source has 3 element(s) but target allows only 2.

As you can see above, MyTupleType cannot accept the array whose order is “number and string”, and the array whose number of members is more than or less than two.

What is the benefit of Tuples?

If the order of members in an array affects your program, Tuple Type will bring benefits to you. For instance, you may pass arguments to a function by using the … rest parameters syntax.

Here is a simple example.

type PersonType = [string, number];

const checkAgeToDrink = (name: string, age: number) => {
　　const legalAgeToDrink = 20;
　　const displayName = name[0].toUpperCase() + name.slice(1);
　　const canDrink = age >= legalAgeToDrink;

　　if(canDrink) {
　　　　console.log(displayName + " can drink!");
　　} else {
　　　　console.log(displayName + " has to wait " + (legalAgeToDrink - age) + " years until they can drink.");
　　}
};

const person1: PersonType = ["john", 10];

checkAgeToDrink(...person1);
// OK [LOG]: "John has to wait 10 years until they can drink."

const person2 = ["mary", 21];

checkAgeToDrink(...person2);
// A spread argument must either have a tuple type or be passed to a rest parameter.

const person3: [number, string] = [30, "mike"];

checkAgeToDrink(...person3);
// Argument of type 'number' is not assignable to parameter of type 'string'.

In the example above, only person1 can be passed as … rest parameters because person1 variable guarantees the order of members’ type.

Speaking of person2, you will see the error message from the TypeScript type checker though it will run at runtime without any issues because the type of this variable, (string | number)[], does not guarantee the order of its members. TypeScript type checker notices a potential bug in advance and lets developers know what might be wrong.

When it comes to person3's case, it must be wrong because the order of the members’ type is wrong.

Tuple inferences

When you see the previous example code, you might wonder what is wrong with person2.

Let's look into the details of the difference between person1 and person2.

const person1: PersonType = ["john", 10];
// const person1: PersonType
// type PersonType = [string, number]

const person2 = ["mary", 21];
// const person2: (string | number)[]

As you can see, the type of person2 is automatically inferred as Union-Type Array while person1 is declared with the type annotation to make it the Tuple type. It means you need to explicitly provide a type annotation when you want to use the Tuple type.

Alternative way to use Tuple, Const asserted tuples

It may be annoying for some developers to write type annotations for Tuples since it is just an extra syntax.

If you feel like that, there is another option. That is the so-called “const assertion”.

By providing a const assertion operator after a value, you can make a tuple as follows:

const checkAgeToDrink = (name: string, age: number) => {
    ......
};

const person2 = ["mary", 21] as const;

checkAgeToDrink(...person2); // OK

Please keep in your mind that the tuples created by a const assertion are not completely the same as a tuple created with an explicit type annotation because the const assertion gives a read-only feature to a value.

const person2 = ["mary", 21] as const;
// const person2: readonly ["mary", 21]

person2[0] = "leo";
// Cannot assign to '0' because it is a read-only property.

Summary

There is a specific type of array that is called a “Tuple” in TypeScript
Tuples are more strict and can store only a static number of elements and types at each index, while Union-type arrays are more flexible
Tuple type cannot accept arrays whose order of types is different and the number of members is different.
If the order of members in an array affects your program, Tuple Type will bring benefits to developers
If you want to use Tuples, there are two ways of doing it.
- Explicit annotations
- Const assertions

What is "void" in TypeScript

Tomohiro Yoshida — Fri, 10 Mar 2023 03:59:23 +0000

In this article, you will learn how "void" behaves in the TypeScript code.

Definition of "void" in the doc

"void" is a kind of type in TypeScript. Let's take a look at the official doc.

void is a little like the opposite of any: the absence of having any type at all. You may commonly see this as the return type of functions that do not return a value:

function warnUser(): void {
  console.log("This is my warning message");
}

And then there is another example:

Declaring variables of type void is not useful because you can only assign null (only if strictNullChecks is not specified, see next section) or undefined to them:

let unusable: void = undefined;
// OK if `--strictNullChecks` is not given
unusable = null;

Speaking of the second example, in other words, you can assign only undefined to the variable in case strictNullChecks is turned on.
But you do not have to remember this because there is no reason to use void even if you want a variable to allow to accept only undefined. You can use undefined type instead.

How to use "void" with Function Types

To quote from the official documentation, "void" can be expressed as follows:

the absence of having any type at all

However, this explanation is not enough to utilize this type with function types in real-world development.
Specifically speaking, if you assign void to a function type as the return type, the type checker will ignore whatever type is returned by the function.

Here is an example code to demonstrate how void works with Function Types:

type returnVoidFuncType = (arg: string) => void;
type returnStringFuncType = (arg: string) => string;

function parentFuncThatWantsVoidCallback(callBack: returnVoidFuncType) {
    callBack("test");
}

function parentFuncThatWantsStringCallback(callBack: returnStringFuncType) {
    console.log(callBack("test"));
}

function childVoidFunc(arg: string) {
    console.log(arg)
}

function childStringFunc(arg: string) {
    return arg;
}

console.log("== Parent Function A ==")
console.log("Expect a callback function that returns 'void'")
parentFuncThatWantsVoidCallback(childVoidFunc);
parentFuncThatWantsVoidCallback(childStringFunc);

console.log("== Parent Function B ==")
console.log("Expect a callback function that returns 'string'")
parentFuncThatWantsStringCallback(childVoidFunc);
parentFuncThatWantsStringCallback(childStringFunc);

You can copy&paste the above code to the TypeScript playground if you want to play with that.

Okay, let me explain the code step by step!

We define two types of function types: returnVoidFuncType and returnStringFuncType.
First, returnVoidFuncType is a type whose returned value is void. On the other hand, returnStringFuncType expects its returned value's type is string.
We also define two parent functions that take in these function types as arguments: parentFuncThatWantsVoidCallback and parentFuncThatWantsStringCallback.

type returnVoidFuncType = (arg: string) => void;
type returnStringFuncType = (arg: string) => string;

function parentFuncThatWantsVoidCallback(callBack: returnVoidFuncType) {
    callBack("test");
}

function parentFuncThatWantsStringCallback(callBack: returnStringFuncType) {
    console.log(callBack("test"));
}

We then declare two child functions: childVoidFunc and childStringFunc.
The first child function, childVoidFunc does not return anything (strictly speaking, it returns undefined due to JavaScript's default behaviour), whereas the latter returns a string.

function childVoidFunc(arg: string) {
    console.log(arg)
}

function childStringFunc(arg: string) {
    return arg;
}

Let's see what happens if we pass these child functions to each parent function as a callback function.

parentFuncThatWantsVoidCallback(childVoidFunc); // OK
parentFuncThatWantsVoidCallback(childStringFunc); // OK

parentFuncThatWantsStringCallback(childVoidFunc); // Type checker warns
// Argument of type '(arg: string) => void' is not assignable to parameter of type 'returnStringFuncType'.
//  Type 'void' is not assignable to type 'string'.(2345)
parentFuncThatWantsStringCallback(childStringFunc); //OK

We can see that parentFuncThatWantsVoidCallback can accept both child functions, including the one that returns string.

In contrast, parentFuncThatWantsStringCallback cannot accept childVoidFunc, whose return type is void.

In short, if a type of the returned value of a Function Type is void, functions that return any type can be assigned or passed because void means "ignoring a type of the returned value".

Why "void" Ignores Types of a Returned Value?

Please look at the example code below:

const array = [1, 2, 3, 4];
const emptyArray = [];

array.forEach((num) => emptyArray.push(num));

Examining the type of the forEach method, you can see this type definition:

(method) Array<number>.forEach(callbackfn: (value: number, index: number, array: number[]) => void, thisArg?: any): void

The forEach method expects a callback function whose type of the returned value is void because the forEach method does not want to do anything to the returned value from the callback function. Actually, the type of the returned value from the push method is number as follows:

(method) Array<any>.push(...items: any[]): number

This is a good example of understanding why void ignores types instead of rejecting them that are not undefined.

Conclusion

As you see above, void is often used with Function Types that expect no value will be returned. However, strictly speaking, void ignores what types are returned rather than it expects no value should be returned.

Object Types (TypeScript)

Tomohiro Yoshida — Thu, 02 Mar 2023 09:55:59 +0000

What you should know about Object Types in TypeScript

I will mainly talk about these two topics in this article.

Structural Typing
Discriminated Unions

This article is inspired by Learning TypeScript written by Josh Goldberg. I highly recommend reading this book if you want to learn TypeScript more.

What are Object Types and how to use them

If you declare a new object, TypeScript will consider it a new object type.

In real-world development, it’s common to utilize Aliased Object Types.

I intentionally use “type” instead of “interface” in this article because I expect some readers of this article may not know about “interface” yet. But the type will be interchangeable in most cases if you’ve already been familiar with the interface.

type Vehicle = {
   wheels: number;
   plate: string;
   run: () => void;
}

const car: Vehicle = {
   wheels: 4,
   plate: "aa2-cc4",
   run: () => {console.log("This car runs very fast!")}
}

If objects’ properties are not precisely the same when you initialize objects with Type annotation, TypeScript yells at you.

type Vehicle = {
   wheels: number;
   plate: string;
   run: () => void;
}

const runner: Vehicle = {
   run: () => {console.log("This runner runs very fast!")}
}
// Type '{ drive: () => void; }' is missing the following properties from type 'Vehicle': wheels, plate

const airplane: Vehicle = {
    wheels: 3,
    plate: "11b-334",
    run: () => {console.log("This plane runs to departure!”)},
    fly: () => {console.log("This plane flies very high!”)}
}
// Type '{ wheels: number; plate: string; run: () => void; fly: () => void; }' is not assignable to type 'Vehicle'. Object literal may only specify known properties, and 'fly' does not exist in type 'Vehicle'.

So far so good, right?

Okay, it’s a good time to dive into the TypeScript world deeply.

Structural Typing

Please guess what happens in the example below:

type Runner = {
    run: () => void;
}

type Vehicle = {
   wheels: number;
   plate: string;
   run: () => void;
}

const car: Vehicle = {
   wheels: 4,
   plate: "aa2-cc4",
   run: () => {console.log("This car runs very fast!")}
}

const startToRun = (arg: Runner) => {
    arg.run();
}

startToRun(car);

Will TypeScript alert you? What do you think?

The answer is No.

You can execute the code without any error messages and see the log "This car runs very fast!" in the console.

It is the concept of Structural Typing, which is described in the Learning TypeScript book as follows:

TypeScript’s type system is structurally typed: meaning any value that happens to satisfy a type is allowed to be used as a value of that type.

In other words, TypeScript does not care if there are extra properties. But it matters if a given value can satisfy the properties of the type.

Let’s look back at the previous example again.

type Runner = {
    run: () => void;
}

type Vehicle = {
   wheels: number;
   plate: string;
   run: () => void;
}

const car: Vehicle = {
   wheels: 4,
   plate: "aa2-cc4",
   run: () => {console.log("This car runs very fast!")}
}

const startToRun = (arg: Runner) => {
    arg.run();
}

startToRun(car);

In this example, the car variable is compatible to be an argument of the startToRun function because the Vehicle type can satisfy the run property in the Runner type.

Let me show one more example:

type Runner = {
    run: () => void;
}

type Vehicle = {
   wheels: number;
   plate: string;
   run: string;
}

const car: Vehicle = {
   wheels: 4,
   plate: "aa2-cc4",
   run: "boom"
}

const startToRun = (arg: Runner) => {
    console.log(arg.run());
}

startToRun(car);
// Argument of type 'Vehicle' is not assignable to parameter of type 'Runner'.
    // Types of property 'run' are incompatible.
    // Type 'string' is not assignable to type '() => void'.

In the above example, the type of the run property in the Vehicle type is string that is a different type from the run property in the Runner type. Therefore, TypeScript says that Types of property 'run' are incompatible.

Discriminated Unions

Once you understand how to use Object Types, you will want to use them with Union.

Please take a look at an example:

type EBook = {
    title: string;
    megabyte: number;
}

type PaperBook = {
    title: string;
    pages: number;
}

type Book = EBook | PaperBook;

const book: Book = Math.random() > 0.5
    ? {title: 'Enjoy cooking', megabyte: 200}
    : {title: 'Learning History', pages: 300};

book.title; // No warning

book.megabyte
// Property 'megabyte' does not exist on type 'Book'.
//  Property 'megabyte' does not exist on type 'PaperBook'.

book.pages
// Property 'pages' does not exist on type 'Book'.
//  Property 'pages' does not exist on type 'EBook'.

TypeScript warns when accessing the megabyte and pages properties because these properties will potentially not exist in the Book type.

If you want to access megabyte or pages, you should use the technique of “Narrowing” to narrow down the possibility of the existence of properties.

Here is an example:

if("megabyte" in book) {
    book.megabyte; // No type error
} else {
    book.pages; // No type error
}

The logic for narrowing down types is the so-called type guard.

There is another solution for narrowing down Unions. You can add a property whose value indicates the object’s type to union-typed objects.

type EBook = {
    title: string;
    megabyte: number;
    format: 'digital';
}

type PaperBook = {
    title: string;
    pages: number;
    format: 'paper';
}

type Book = EBook | PaperBook;

const book: Book = Math.random() > 0.5
    ? {title: 'Enjoy cooking', megabyte: 200, format: 'digital'}
    : {title: 'Learning History', pages: 300, format: 'paper'};

if(book.format === 'digital') {
    book.megabyte; // No type error
} else {
    book.pages; // No type error
}

Perfect! You can safely access the properties that will potentially not exist by this technique.

The union-typed object with this shape is called a discriminated union. And the property that is used as an identifier of union typed objects is a discriminant.

Are you wondering why string values can be a type?

Good point. Actually, 'digital' and 'paper' in this code is literal types that are more specific versions of primitive types. Therefore, you can consider 'digital' and 'paper' as types in the above example code.

Conclusion

Object Types are a powerful technique to take advantage of TypeScript features.

One important fact that you should keep in mind is that the type system in TypeScript is Structural Typing which means you can use any value satisfying a type as a value of that type. (It does not matter whether the value has extra properties and a different name of a type.)

When it comes to making a union of object types, you can add a discriminant to object types. And the shape of union typed objects that have discriminant is considered as a discriminated union.