Think of TypeScript as a helpful assistant who looks over your shoulder while you write JavaScript. It quietly points out potential mistakes before you even run your code, asking questions like, “Are you sure you want to pass a string to a function that expects a number?” This simple change—catching errors earlier—transforms how you build things. Let me show you some practical ways to use it.

I start with explicit type annotations. It’s like labeling the boxes when you move house. You wouldn’t write “stuff” on every box; you’d write “kitware,” “books,” “fragile.” Code benefits from the same clarity.

Here’s a common JavaScript function.

function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

What is items? An array of what? What does item.price look like? In JavaScript, you find out at runtime. In TypeScript, you declare it upfront.

interface CartItem {
  id: number;
  name: string;
  price: number;
  quantity: number;
}

function calculateTotal(items: CartItem[]): number {
  return items.reduce((sum, item) => sum + (item.price * item.quantity), 0);
}

Now, the function’s contract is crystal clear. If I try to pass an array of strings, TypeScript will warn me immediately. My editor will also autocomplete item.price and item.quantity as I type. This isn’t just about preventing errors; it’s about creating code that explains itself.

The next tool I use constantly is the interface. An interface is a blueprint for an object’s shape. It defines what properties must exist, what their types are, and which ones are optional. This is powerful for ensuring consistency across your application.

Imagine you’re building a user profile system. In plain JavaScript, a user object might come from an API, a form, or a database. Its structure could subtly change in different parts of your app.

interface UserProfile {
  userId: string;
  displayName: string;
  emailAddress: string;
  dateOfBirth?: Date; // The '?' means this property is optional
  profilePictureUrl?: string;
}

function sendWelcomeEmail(user: UserProfile): void {
  // TypeScript knows that `user.emailAddress` is a string.
  console.log(`Sending email to ${user.emailAddress}`);
  // TypeScript also knows `user.dateOfBirth` might be undefined.
  if (user.dateOfBirth) {
    console.log(`Birthday is on ${user.dateOfBirth.toISOString()}`);
  }
}

// The compiler will check this object against the interface.
const newUser: UserProfile = {
  userId: 'usr_123',
  displayName: 'Jamie Smith',
  emailAddress: '[email protected]'
  // `dateOfBirth` is optional, so we can omit it.
};

If I later try to assign newUser.twitterHandle, TypeScript will stop me because that property isn’t in the blueprint. This prevents a whole class of bugs where you misspell a property name or assume data exists when it doesn’t.

Real-world data is often messy. A value might be a string or a number. An operation might succeed or fail. Union types are how I model this uncertainty in a safe way. They let you say a variable can be one of several types.

Consider a function that formats an identifier. Maybe the ID is sometimes a number from a legacy database and sometimes a new UUID string.

type Identifier = string | number;

function formatForDisplay(id: Identifier): string {
  // We need to check the type first.
  if (typeof id === 'string') {
    return `ID: ${id.toUpperCase()}`;
  } else {
    // TypeScript knows here that `id` must be a number.
    return `ID: #${id.toString().padStart(6, '0')}`;
  }
}

console.log(formatForDisplay('abc123')); // "ID: ABC123"
console.log(formatForDisplay(42));       // "ID: #000042"
// console.log(formatForDisplay(true));  // Error: boolean isn't allowed.

This process of checking the type with an if statement is called type narrowing. TypeScript’s compiler follows your logic. Inside the if block, it knows id is a string. In the else block, it knows id is a number. This allows you to use type-specific methods like .toUpperCase() safely.

Union types are also perfect for representing states, like the result of an API call.

type ApiResponse = 
  { status: 'success'; data: UserProfile[] } |
  { status: 'error'; message: string; code: number };

function handleResponse(response: ApiResponse) {
  if (response.status === 'success') {
    // TypeScript knows `response.data` exists here.
    console.log(`Received ${response.data.length} users`);
  } else {
    // TypeScript knows `response.message` and `response.code` exist here.
    console.error(`Error ${response.code}: ${response.message}`);
  }
}

This pattern eliminates null reference errors. You are forced to handle both the success and error cases, which makes your code more robust.

As your application grows, you’ll write functions and components that should work with different kinds of data. You don’t want to write the same logic for arrays of strings, numbers, and user objects. This is where generics come in. They let you create reusable code that maintains type information.

Think of a simple function that returns the first element of an array.

// Without generics, you lose the type.
function getFirstElement(arr: any[]): any {
  return arr[0];
}
const num = getFirstElement([1, 2, 3]); // Type is 'any'. We've lost safety.

// With generics, you preserve the type.
function getFirstElement<T>(arr: T[]): T | undefined {
  return arr[0];
}

const numbers = getFirstElement([1, 2, 3]);     // TypeScript knows `numbers` is `number | undefined`
const strings = getFirstElement(['a', 'b', 'c']); // TypeScript knows `strings` is `string | undefined`

The <T> is a type parameter. It’s a placeholder. When you call the function with a number array, T becomes number. When you call it with a string array, T becomes string. The function is generic, but its use is perfectly typed.

Generics are essential for building data structures like a simple queue.

class Queue<T> {
  private data: T[] = [];

  enqueue(item: T): void {
    this.data.push(item);
  }

  dequeue(): T | undefined {
    return this.data.shift();
  }
}

// Create a queue for numbers.
const numberQueue = new Queue<number>();
numberQueue.enqueue(10);
numberQueue.enqueue(20);
const firstNumber = numberQueue.dequeue(); // Type is `number | undefined`

// Create a queue for our UserProfile objects.
const userQueue = new Queue<UserProfile>();
userQueue.enqueue(newUser);
const firstUser = userQueue.dequeue(); // Type is `UserProfile | undefined`

I only wrote the Queue class once, but I can use it safely with any type. The generic <T> acts as a contract: “Whatever type you give me when you create the queue, that’s the type of items that will go in and come out.”

Sometimes, type narrowing with typeof or checking a property isn’t enough. You might have complex logic to determine what kind of object you’re dealing with. For this, I write type guard functions. A type guard is a function that returns a boolean and has a special return type that tells TypeScript, “If this function returns true, the parameter is of this specific type.”

Let’s say I have different kinds of notifications in my app.

interface EmailNotification {
  type: 'email';
  to: string;
  subject: string;
  body: string;
}

interface PushNotification {
  type: 'push';
  deviceToken: string;
  title: string;
  message: string;
}

type Notification = EmailNotification | PushNotification;

// This is the type guard. Notice the `parameter is Type` syntax.
function isEmailNotification(notif: Notification): notif is EmailNotification {
  return notif.type === 'email';
}

function sendNotification(notif: Notification) {
  if (isEmailNotification(notif)) {
    // In this block, TypeScript knows `notif` is an EmailNotification.
    console.log(`Sending email to ${notif.to}: ${notif.subject}`);
    // `notif.deviceToken` would be an error here.
  } else {
    // Therefore, here it must be a PushNotification.
    console.log(`Sending push to ${notif.deviceToken}`);
  }
}

The type guard isEmailNotification encapsulates the validation logic. This makes the main function cleaner and allows me to reuse the guard elsewhere. It’s a perfect blend of runtime check and compile-time type safety.

You’ll often find yourself needing a variation of an existing type. Maybe you need all properties to be optional for an update, or you need a read-only version for a configuration object. Instead of creating new interfaces from scratch, TypeScript provides utility types to transform existing ones.

Let’s go back to our Product interface.

interface Product {
  id: number;
  name: string;
  price: number;
  inStock: boolean;
}

What if I have a function that updates a product, but it only needs to change some fields?

// `Partial<T>` makes every property in T optional.
function updateProduct(id: number, updates: Partial<Product>) {
  // In a real app, you would merge `updates` with the existing product.
  console.log(`Updating product ${id} with:`, updates);
}

// This is valid because all properties are optional with Partial.
updateProduct(5, { price: 29.99 });
updateProduct(5, { name: 'New Name', inStock: false });

What if I have a configuration object I should never modify after creation?

// `Readonly<T>` makes all properties of T read-only.
const appConfig: Readonly<Product> = {
  id: 0,
  name: 'Default Product',
  price: 0,
  inStock: false
};

// appConfig.price = 100; // Compiler Error: Cannot assign to 'price' because it is a read-only property.

What if I want to create a type for a product summary, which only needs the id and name?

// `Pick<T, K>` creates a type by picking the set of properties K from T.
type ProductSummary = Pick<Product, 'id' | 'name'>;

const summary: ProductSummary = {
  id: 12,
  name: 'Coffee Mug'
  // No need for `price` or `inStock`.
};

These utility types keep your code DRY (Don’t Repeat Yourself). You define the main source of truth once and derive other shapes from it. If your main Product interface changes, ProductSummary and your update functions will automatically reflect those changes in a type-safe way.

The JavaScript ecosystem is vast, and not every library is written in TypeScript. To use them without losing type safety, TypeScript uses declaration files (with a .d.ts extension). These files describe the shape of the existing JavaScript library—what functions it exports, what parameters they take.

You don’t usually write these from scratch; the community provides them for most major libraries via @types packages. But understanding them is useful. Imagine a simple, old JavaScript library for formatting dates.

// In a file called `legacy-formatter.js`
export function formatDate(date, formatString) {
  // ... some logic
  return formattedString;
}

To use this in my TypeScript project, I could create a declaration file.

// `legacy-formatter.d.ts`
declare module 'legacy-formatter' {
  export function formatDate(date: Date, formatString: string): string;
}

Now, when I import it, TypeScript has the type information.

import { formatDate } from 'legacy-formatter';

const today = new Date();
const formatted = formatDate(today, 'yyyy-mm-dd'); // Works with full type checking.
// const wrong = formatDate('not a date', 'yyyy'); // Error: Argument of type 'string' is not assignable to parameter of type 'Date'.

This system is what allows you to use the entire npm ecosystem seamlessly. It tells TypeScript, “Trust me, this JavaScript module exists, and here’s what it looks like.” The compiler then enforces those types in your code.

These seven techniques form a toolkit. You don’t need to use them all at once. Start by adding basic type annotations to your function parameters and return values. Then, as you encounter objects, define an interface. When you need flexibility, reach for a union type. When you see duplication, consider a generic or a utility type.

The goal isn’t to add complex types for their own sake. The goal is to make your JavaScript development more predictable and less frustrating. It’s about having a conversation with your compiler. You tell it what you intend, and it helps you stay on track. Over time, this shifts your mental load from “did I remember all the edge cases?” to “my code expresses what it should do.” That’s a much more confident way to build.