Use of Any Type in TypeScript

While reviewing the code of a TypeScript project, I noticed a variable using the ‘any’ type. It was referred in many places to avoid type errors. Some developers think that it is the easiest way to make the code work. But later, using any keyword too much can hide problems and remove the benefits of TypeScript’s type checking.

In this article, I’ll explain what the any type really means, when to use any type in TypeScript, and why you should be careful with it. I’ll also show you some better and safer ways to handle situations where using “any” might seem like the only option.

What is the ‘any’ Type in TypeScript?

The ‘any’ type is TypeScript’s way of representing dynamic values that can be of any type. It effectively turns off type checking for a particular variable, allowing it to hold values of any type and access any properties or methods.

Here’s a simple example:

let userInput: any = 5;
console.log("Initial userInput:", userInput);  // Output: 5

userInput = "Hello USA";
console.log("userInput after string assignment:", userInput);  // Output: Hello USA

userInput = true;
console.log("userInput after boolean assignment:", userInput);  // Output: true

// This won't throw a compile-time error but will break at runtime
console.log("Trying to call non-existent method...");
userInput.thisMethodDoesntExist();  // Runtime error

Output:

When you declare a variable with type ‘any’, TypeScript doesn’t perform any type checking on it. This can be both powerful and dangerous.

Check out: Mapped Types in TypeScript

When to Use the ‘any’ Type

Working with Third-Party Libraries

Sometimes, when integrating with libraries that don’t have TypeScript definitions, using ‘any’ can be a quick solution:

// Imagine a US stock market API without TypeScript definitions
const marketData: any = getMarketData('NASDAQ');
const appleStock = marketData.stocks.AAPL;  // No type checking, but works

Output:

Gradual Migration from JavaScript

When migrating a large JavaScript codebase to TypeScript, using ‘any’ can help make the transition smoother:

// Original JavaScript code
function processUserData(user) {
  return user.firstName + ' ' + user.lastName;
}

// Quick TypeScript conversion with 'any'
function processUserData(user: any): string {
  return user.firstName + ' ' + user.lastName;
}

Output:

Check out: TypeScript Exception Handling

Complex or Dynamic Data Structures

When dealing with highly complex or truly dynamic data structures, ‘any’ might be appropriate:

// Parsing a complex, nested JSON response from a US government API
const censusData: any = JSON.parse(responseText);

Why You Should Avoid ‘any’ When Possible

Loss of Type Safety

The main drawback of ‘any’ is that you lose TypeScript’s compile-time checks:

function getStateTaxRate(state: any) {
  return state.taxRate * 100;  // No error if state or taxRate is undefined
}

// This will compile but fail at runtime
const taxRate = getStateTaxRate({name: 'California'});  // Runtime error: Cannot read property 'taxRate' of undefined

Output:

Check out: Use For Loop Range in TypeScript

Reduced IDE Support

When using ‘any’, you lose IDE features like autocompletion and refactoring support:

const customer: any = getCustomer();
// No autocompletion for customer properties

Hinders Team Collaboration

Using ‘any’ makes it harder for other developers to understand what data structures your code expects:

// What does this function expect? Hard to tell
function processOrder(order: any): any {
  // Implementation
}

Better Alternatives to ‘any’

Using ‘unknown’ Instead

The ‘unknown’ type is a type-safe alternative to ‘any’. It represents a value that could be anything, but you must perform type checking before using it:

function processUserInput(input: unknown): string {
  console.log("Input received:", input);

  if (typeof input === 'string') {
    console.log("Input is a string");
    return input.toUpperCase();
  }

  console.log("Input is not a string, converting to string");
  return String(input);
}

console.log(processUserInput("hello world"));
console.log(processUserInput(1234));

Output:

Type Assertions

When you know more about a type than TypeScript does, you can use type assertions:

interface TaxData {
  state: string;
  rate: number;
}

const responseText = '{"state":"California","rate":7.25}';

let taxData: TaxData;

try {
  const parsed = JSON.parse(responseText);

  // Basic validation before type assertion
  if (parsed && typeof parsed.state === 'string' && typeof parsed.rate === 'number') {
    taxData = parsed as TaxData;
    console.log(`${taxData.state} tax rate: ${taxData.rate}%`);
  } else {
    console.error("Parsed data does not match TaxData structure.");
  }

} catch (error) {
  console.error("Failed to parse responseText:", error);
}

Output:

Partial Type Definitions

Instead of using ‘any’ for an entire object, define the parts you know and use optional properties:

interface ApiResponse {
  status: number;
  message: string;
  data?: any;
}

const apiResponse: ApiResponse = {
  status: 200,
  message: "OK",
  data: { userId: 101, name: "Jane" }
};

console.log("API Response:", apiResponse);

Output:

Using Generic Types

Generics provide flexibility without sacrificing type safety:

function processArray<T>(items: T[]): T {
  return items[0];
}

const firstState = processArray(['California', 'Texas', 'Florida']);  // Type is string
const firstZipCode = processArray([90210, 10001, 60601]);  // Type is number

Real-World Example: US Tax Calculator

Let’s look at a more complex example. Imagine we’re building a US tax calculator that processes different types of income:

// Bad approach using 'any'
function calculateTax(income: any): number {
  if (income.type === 'salary') {
    return income.amount * 0.3;
  } else if (income.type === 'investment') {
    return income.amount * 0.15;
  }
  return 0;
}

// Better approach with proper types
type SalaryIncome = {
  type: 'salary';
  amount: number;
  employer: string;
};

type InvestmentIncome = {
  type: 'investment';
  amount: number;
  source: string;
};

type Income = SalaryIncome | InvestmentIncome;

function calculateTax(income: Income): number {
  if (income.type === 'salary') {
    return income.amount * 0.3;
  } else if (income.type === 'investment') {
    return income.amount * 0.15;
  }
  // TypeScript knows we've handled all possibilities
  return 0;
}

Output using any:

Using Proper types:

Check out: TypeScript forEach Loop with Index

Migrating Away from ‘any’

If you’ve used ‘any’ extensively in your project, here are steps to gradually reduce its usage:

1. Enable stricter TypeScript settings in your tsconfig.json:

   {
     "compilerOptions": {
       "noImplicitAny": true,
       "strictNullChecks": true
     }
   }

2. Use the TypeScript compiler to find ‘any’ usages:

   npx tsc --noEmit --findAllErrorsWithoutAny

3. Start with high-value code like public APIs and critical business logic.
4. Use better types incrementally, focusing on one module at a time

Check out: Implement Sleep Function in TypeScript

Conclusion

While the ‘any’ type in TypeScript provides an easy escape hatch from the type system, it should be used judiciously. In my experience, most uses of ‘any’ can be replaced with better alternatives like ‘unknown’, union types, or generics that maintain type safety while providing the flexibility you need.

Remember, TypeScript’s power comes from its ability to catch errors at compile time rather than runtime. Every ‘any’ in your code represents a potential bug that TypeScript can’t help you find.

Bijay Kumar

I am Bijay Kumar, a Microsoft MVP in SharePoint. Apart from SharePoint, I started working on Python, Machine learning, and artificial intelligence for the last 5 years. During this time I got expertise in various Python libraries also like Tkinter, Pandas, NumPy, Turtle, Django, Matplotlib, Tensorflow, Scipy, Scikit-Learn, etc… for various clients in the United States, Canada, the United Kingdom, Australia, New Zealand, etc. Check out my profile.

enjoysharepoint.com/