In partnership with

I love ❤️ TypeScript.

Especially after experiencing JavaScript's infamous "cannot access value of undefined" errors.

However, even though TypeScript is great, there are still ways to shoot yourself in the foot.

In this post, I'll share 5 bad practices in TypeScript and how to avoid them.

Table of Contents

• 💰 This Week Sponsor

• 1. Declaring Errors as Type Any

• 2. Having Functions with Multiple Consecutive Para …

• 3. Having a Function with Multiple Branches and No …

• 4. Adding Unnecessary Types Instead of Using Optio …

• 5. Making Properties Optional at Different Compone …

• Summary

• 🐞 SPOT THE BUG

💰 This Week Sponsor

Drowning In Support Tickets? Maven AGI is here to help.

Maven AGI platform simplifies customer service by unifying systems, improving with every interaction, and automating up to 93% of responses. Seamlessly integrated with 50+ tools like Salesforce, Freshdesk, and Zendesk, Maven can deploy AI agents across multiple channels—text, email, web, voice, and apps—within days. Companies like Tripadvisor, ClickUp, and Rho slash response times by 60%, ensuring quicker support and exceptional customer satisfaction. Don’t let support tickets slow you down

Request a free personalized demo today.

1. Declaring Errors as Type Any

Example

In the following code snippet, we catch the error then declare it as type any.

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err: any) {
    toast(`Failed to do something: ${err.message}`);
  }
}

Why it is bad ❌

There is no guarantee that the error has a message field of type string.

Unfortunately, because of the type assertion, the code lets us assume it does.

The code can work in development with specific test cases but can break badly in production.

What to do instead ✅

Don't set the type of error. It should be unknown by default.

Instead, you can do any of the following:

• Option 1: Check if the error is of the correct type with a type guard.

async function asyncFunction() {
  try {
    const response = await doSomething();
    return response;
  } catch (err) {
    const toastMessage = hasMessage(err)
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;
    toast(toastMessage);
  }
}

// We use a type guard to check first
function hasMessage(value: unknown): value is { message: string } {
  return (
    value != null &&
    typeof value === "object" &&
    "message" in value &&
    typeof value.message === "string"
  );
}

// You can also simply check if the error is an instance of Error
const toastMessage = err instanceof Error
      ? `Failed to do something: ${err.message}`
      : `Failed to do something`;

• Option 2 (Recommended): Don't make assumptions about the error

Instead of making assumptions about the error type, handle each type explicitly and provide appropriate feedback to the user.

If you can't determine the specific error type, it's better to show complete error information rather than partial details.

For more information about error handling, check out this excellent guide: Writing Better Error Messages.

2. Having Functions with Multiple Consecutive Parameters of the Same Type

Example

export function greet(
  firstName: string,
  lastName: string,
  city: string,
  email: string
) {
  // Do something...
}

Why it is bad ❌

• You can accidentally pass parameters in the wrong order:

// We inverted firstName and lastName, but TypeScript won't catch this
greet("Curry", "Stephen", "LA", "[email protected]")

• It's harder to understand what each parameter represents, especially during code reviews, when seeing the function call before its declaration

What to do instead ✅

Use an object parameter to clarify each field's purpose and minimize the risk of mistakes.

export function greet(params: {
  firstName: string;
  lastName: string;
  city: string;
  email: string;
}) {
  // Do something...
}

3. Having a Function with Multiple Branches and No Return Type

Example

function getAnimalDetails(animalType: "dog" | "cat" | "cow") {
  switch (animalType) {
    case "dog":
      return { name: "Dog", sound: "Woof" };
    case "cat":
      return { name: "Cat", sound: "Meow" };
    case "cow":
      return { name: "Cow", sound: "Moo" };
    default:
      // This ensures TypeScript catches unhandled cases
      ((_: never) => {})(animalType);
  }
}

Why it is bad ❌

• Adding a new animalType could lead to returning an incorrectly structured object.

• Changes to the return type structure can cause hard-to-trace issues in other parts of the code.

• Typos can result in incorrect types being inferred.

What to do instead ✅

Explicitly specify the function's return type:

type Animal = {
  name: string;
  sound: string;
};

function getAnimalDetails(animalType: "dog" | "cat" | "cow"): Animal {
  switch (animalType) {
    case "dog":
      return { name: "Dog", sound: "Woof" };
    case "cat":
      return { name: "Cat", sound: "Meow" };
    case "cow":
      return { name: "Cow", sound: "Moo" };
    default:
      // This ensures TypeScript catches unhandled cases
      ((_: never) => {})(animalType);
  }
}

4. Adding Unnecessary Types Instead of Using Optional Fields

Example

type Person = {
    name: string;
    age: number;
}

type PersonWithAddress = Person & {
    address: string;
}

type PersonWithAddressAndEmail = PersonWithAddress & {
    email: string;
}

type PersonWithEmail = Person & {
    email: string;
}

Why it is bad ❌

• Doesn't scale: adding new fields requires creating multiple new types

• Makes type checking more complex, requiring additional type guards

• Leads to confusing type names and harder maintenance

What to do instead ✅

Use optional fields to keep your types simple and maintainable:

type Person = {
  name: string;
  age: number;
  address?: string;
  email?: string;
};

5. Making Properties Optional at Different Component Levels

Example

The disabled prop is optional in all the components.

interface TravelFormProps {
    disabled?: boolean;
}

export function TravelForm(props: TravelFormProps) {
    // Uses the date range picker component...
}

interface DateRangePickerProps {
  disabled?: boolean;
}

function DateRangePicker(props: DateRangePickerProps) {
  // Uses the date picker component...
}

interface DatePickerProps {
  disabled?: boolean;
}

function DatePicker(props: DatePickerProps) {}

Why it is bad ❌

• Easy to forget to pass the disabled prop, resulting in partially enabled forms

What to do instead ✅

Make the shared fields required for internal components.

This will ensure proper prop passing. This is especially important for lower-level components to catch any oversights early.

In the example above, disabled is now required in all the internal components.

interface TravelFormProps {
    disabled?: boolean;
}

export function TravelForm(props: TravelFormProps) {
    // Uses the date range picker component...
}

interface DateRangePickerProps {
  disabled: boolean | undefined;
}

function DateRangePicker(props: DateRangePickerProps) {
  // Uses the date picker component...
}

interface DatePickerProps {
  disabled: boolean | undefined;
}

function DatePicker(props: DatePickerProps) {}

Summary

TypeScript is amazing, but no tool 🛠️ is perfect.

Avoiding these 5 mistakes will help you write cleaner, safer, and more maintainable code.

For more tips, check out my free e-book, 101 React Tips & Tricks.

🐞 SPOT THE BUG

🐞 TIP OF THE WEEK