Skip to content
Menu
Rohit Naik Kundaikar
  • Home
  • Contact
Rohit Naik Kundaikar

Typescript Guide – Part 1

Posted on August 2, 2024August 2, 2024 by Rohit Naik Kundaikar

Strict Typecheck

To enforce stricter type checking in TypeScript and ensure that developers specify types consistently, you can enable strict type checking by configuring your tsconfig.json file. By setting the strict flag to true, you enable all of TypeScript’s strict type-checking options at once:

{
  "compilerOptions": {
    "strict": true
  }
}

Alternatively, if you prefer more granular control, you can enable individual strict flags based on your specific needs. For example:

  • "strictNullChecks": Ensures that null and undefined are handled explicitly.
  • "strictFunctionTypes": Provides stricter function type checks.
  • "strictPropertyInitialization": Ensures that class properties are correctly initialized.

Using strict null checks can help catch potential issues related to null and undefined values at compile-time, which can reduce the likelihood of runtime errors.

Props and State Type

In React, it is important to define the types for props and state to ensure type safety and prevent potential runtime errors. Each component should explicitly specify the types for its props using prop types or interfaces.

Avoid using the any type, as it bypasses TypeScript’s type-checking capabilities. If you’re unsure of an object’s type, take the time to research or ask for help to find the correct type.

Generics Vs Any Type

In TypeScript, generics provide a way to create reusable components and functions while maintaining type safety. Unlike the any type, which bypasses type checking and can lead to runtime errors, generics ensure that the type information is preserved throughout your code.

Example

Consider a function that fetches data from an API. You can use generics to specify the type of data returned by the function, ensuring type safety without sacrificing flexibility.

Here’s a comparison of using any versus generics:

Using any

typescriptCopy code// Function using 'any' type
async function fetchApi(path: string): Promise<any> {
  const response = await fetch(path);
  return response.json();
}

// Example usage
const data: any = await fetchApi('/users');

In the above code, fetchApi returns a value of type any, which means TypeScript cannot provide any type safety for the data variable. You lose the benefits of type checking and could potentially introduce errors if you mismanage the data type.

Using Generics

typescriptCopy code// Define a generic function with a type parameter
async function fetchApi<ResultType>(path: string): Promise<ResultType> {
  const response = await fetch(path);
  return response.json();
}

// Define a specific type
type User = { name: string; };

// Example usage with a specific type
const data: User = await fetchApi<User>('/users');

In this improved version, fetchApi is a generic function that takes a type parameter ResultType. When calling fetchApi, you specify the expected type, such as User, ensuring that the data variable is typed correctly. This preserves type safety and makes your code more robust and maintainable.

By using generics, you maintain type checking across different uses of the function or component, providing clear and predictable type information and reducing potential errors.

Certainly! Here’s a revised explanation about the differences between any, unknown, and never in TypeScript, with examples:


any vs. unknown vs. never

any

The any type allows for any operation on a variable, and TypeScript will not perform any type checking. This can lead to potential issues because it effectively disables type safety.

Example:

const abc: any = 10;
abc++; // This is valid and increments the number
abc.toUpperCase(); // This is also valid but will not work at runtime as 'abc' is a number

In the example above, TypeScript does not enforce any type checks, so both operations are allowed, but they can cause runtime errors or unintended behavior.

unknown

The unknown type is safer than any because you must perform type checking before performing operations on a variable of type unknown. This ensures that you handle different types explicitly and avoid errors.

Example:

const abc: unknown = 10;

// The following operations will throw errors if attempted directly:
abc++; // Error: Operator '++' cannot be applied to type 'unknown'
abc.toUpperCase(); // Error: Property 'toUpperCase' does not exist on type 'unknown'

// You must first check the type before performing operations:
if (typeof abc === 'number') {
  abc++; // This is valid now
}

if (typeof abc === 'string') {
  abc.toUpperCase(); // This is valid now
}

In this example, TypeScript enforces type checks, so you need to check the type of abc before performing operations on it. This helps prevent runtime errors.

never

The never type represents values that never occur. It is used in scenarios such as functions that never return or cases where a function always throws an error.

Example:

function throwError(message: string): never {
  throw new Error(message);
}

function infiniteLoop(): never {
  while (true) {}
}

In these examples, throwError and infiniteLoop both return never, indicating that they do not complete normally. You cannot assign never to any other type or perform operations on never values.

  • any: Disables type checking. Operations on any are allowed, but this can lead to runtime errors due to lack of type safety.
  • unknown: Requires type checking before operations can be performed. It is safer than any because it enforces type safety.
  • never: Represents values that never occur. Used in functions that never return or always throw errors.

By using unknown and never appropriately, you can write safer TypeScript code with better type checking and error handling.

Typescript

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Typescript Guide – Part 1
  • Vite Micro Frontend
  • React Best Practice: Part 2
  • React Best Practices: Part 1
  • Redux Toolkit

Recent Comments

    Archives

    • August 2024
    • January 2024
    • September 2021
    • July 2021
    • June 2021
    • May 2021
    • April 2021
    • December 2020
    • November 2020
    • October 2020
    • September 2020

    Categories

    • Angular
    • API
    • Best Practice
    • Compiler
    • Context
    • DevOps
    • Docker
    • FAANG
    • Forms
    • GraphQL
    • Java
    • Javascript
    • Machine Learning
    • MobX
    • Python
    • ReactJS
    • Redux Toolkit
    • Spring Boot
    • Typescript
    • Uncategorized
    • Vite
    • Webpack
    ©2025 Rohit Naik Kundaikar | Powered by WordPress & Superb Themes