✨ 5 Bad Ideas in TypeScript

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.

📚 Download my FREE 101 React Tips And Tricks Book for a head start.

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", "[e-mail]")

• 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) {}

Note: I don’t recommend this if you are designing components for a library since required fields take more work.

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

That's a wrap 🎉.

Leave a comment 📩 to share a Typescript mistake you made.

And don't forget to drop a "💖🦄🔥".

If you're learning React, download my 101 React Tips & Tricks book for FREE.

If you like articles like this, join my FREE newsletter, FrontendJoy.

If you want daily tips, find me on X/Twitter or on Bluesky.