Section 1.1: Are Type Checks Being Ignored?

TypeScript is built as a superset of JavaScript, meaning that any valid JavaScript code is also valid TypeScript code. This design allows for code that lacks type checks to exist within TypeScript projects. While this flexibility aids in migrating from JavaScript, it is essential to avoid bypassing type checks in a fully TypeScript-based project.

Adopting strict mode is crucial when developing in TypeScript. However, there are ways to inadvertently silence type checks:

• Using any
• Employing // @ts-ignore
• Making unsafe type assertions, such as x as unknown as MyType

Both any and // @ts-ignore should rarely be used in production code. Type assertions can be beneficial, but they should not serve merely to bypass type checking.

Section 1.2: Does the Type Reflect a Valid State?

Types should always represent realistic scenarios within your code. A common issue arises when types permit impossible combinations of values. For example, consider a scenario where you have two types of products: shoes and t-shirts.

type Product = {

kind: "tshirt" | "shoes";

price: number;

shoeSize?: number;

tShirtSize?: 'S' | 'M' | 'L';

};

In this case, TypeScript allows for both shoeSize and tShirtSize to be defined simultaneously, or for a t-shirt to lack its size. To rectify this, we can implement Discriminated Unions.

type BaseProduct = {

id: number;

price: number;

}

type ShoesProduct = BaseProduct & {

kind: 'shoes';

shoeSize: number;

}

type TshirtProduct = BaseProduct & {

kind: 'tshirt';

tShirtSize: 'S' | 'M' | 'L';

}

type Product = ShoesProduct | TshirtProduct;

const product = getProductById(1);

if (product.kind === 'shoes') {

console.log(product.shoeSize);

}

This example demonstrates a more accurate representation of the application logic, eliminating impossible state combinations.

Section 2.1: Is There Redundant Code?

The principle of DRY (Don't Repeat Yourself) is crucial in software development. TypeScript, like any programming language, can become verbose, leading to redundancy. A frequent cause of repeated code is the failure to leverage TypeScript's type inference.

For instance, consider the following code:

interface User {

id: string;

name: string;

}

class UserService {

getUser: (id: string) => User;

}

const userService = new UserService();

const user: User = userService.getUser('123');

In this scenario, we unnecessarily specified the type of user. We can enhance readability by omitting the explicit type:

const user = userService.getUser('123');

TypeScript automatically infers the type, simplifying the code.

Section 2.2: Is the Type as Specific as Possible?

Types define sets of possible values. A type defined as string permits any string, which is often broader than necessary. For example, when defining order statuses, a union type is more appropriate:

type OrderStatus = 'Pending' | 'Processing' | 'Completed' | 'Cancelled';

Using unions or enums provides clear documentation for other developers and offers benefits such as type checking against typos and improved auto-completion suggestions.

Section 2.3: Am I Future-Proofing My Code?

One of the aspects I appreciate about TypeScript is its ability to help future-proof code. For example, consider a JavaScript snippet that lacks safeguards for future changes:

const messageForRole = {

admin: "Hello Admin",

user: "Welcome back!",

};

const user = getUserById(1);

console.log(messageForRole[user.role]);

If a new role, such as "guest," is added without updating messageForRole, it could lead to undefined values and runtime errors. By defining a type for roles, we can enforce that all roles are covered.

type UserRole = 'admin' | 'user' | 'guest';

const messageByRole: Record<UserRole, string> = {

admin: "Hello admin",

user: "Welcome back"

};

This structure prevents deploying faulty code and makes it easier to identify issues.