Using a better alternative to the any type – TypeScript Patterns for Angular

In the development of TypeScript applications, we may have situations where we do not know which type of parameter we are going to receive, such as the return of an API.

What is trafficked can be defined by creating an interface that represents the data, (for more details, see Chapter 5, Angular Services and the Singleton Pattern). It is not possible to guarantee this because pure text is trafficked on the internet.

In these cases, we can use the any type, which prevents TypeScript from doing the type checking.

In this example, we can see the use of any:
interface Products {
  id: number;
   description: string;
}
type ListOfProducts = Array<Products>;
const exampleList: ListOfProducts = [
  { id: 1, description: “banana” },
  { id: 2, description: “apple” },
  { id: 3, description: “pear” },
];
function getProductById(id: any) {
  return exampleList.find((product) => product.id === id);
}

In the preceding code sample, we create an interface that represents a product and a type that represents a list of products. We then create a function that receives an id of the any type and searches the Array, returning an item from the list of products.

In these simple examples, we can assume that there is no bug, but let’s create a function that will use this snippet and see what happens:
export function getProductTest() {
  const id = ‘2’;
  const item = getProductById(id);
  if (item !== undefined) {
    console.log(`ID:${item.id} Description:${item.description}`);
  } else {
    console.log(“No product found”);
  }
}

In this example, the item was not found because the variable we passed was a string. This could happen if the data we are passing to the function came from an API or external call, and the data was not properly formatted.

Running the code, we get the following result:

Figure 3.5 – Function returned No product found due to the id variable typing

When we use the any type, we give up the advantage of type checking and this type of bug can occur in our application. But how can we have the flexibility of the any type without losing TypeScript’s type checking?

In these cases, we use the unknown type. This type has the same flexibility as the any type, but with one detail: TypeScript forces you to perform type guarding before using the variable.

Let’s refactor our example function:
function getProductById(id: unknown) {
  if (typeof id === ‘string’){
    id = parseInt(id);
  } else if (typeof id !== ‘number’){
    return
  }
  return exampleList.find((product) => product.id === id);
}

Here we declare that id will be of an unknown type and, right after that, we make a guard type in this variable, dealing with the possible scenario of the variable being numerical.

The any type will still be used in your application, but consider using the unknown type to ensure correct type handling when you are not sure who will call your function.

Summary

In this chapter, we saw how we can use TypeScript to create better-quality code with less effort, increasing our productivity. We learned about basic TypeScript types, such as number, string, and Array.

We also studied creating classes, interfaces, and type aliases, and how we can choose and mix these types of structures to make our code cleaner and more maintainable.

Finally, we learned about TypeScript’s type inference mechanism and how we can use the concept of type guards to further improve the type-checking mechanism. With these concepts, we also became familiar with the unknown type, which provides a better alternative to the any type.

In the next chapter we will learn about the basics of the interfaces of an Angular project, that is, the Components.