TypeScript Practice

Types disappear at runtime. TypeScript catches bugs at compile time, improves autocomplete, and makes refactors safer—without changing the JavaScript your code produces.

TypeScript doesn't change your runtime code. It adds a compile-time check that catches bugs before they happen:

// This TypeScript...
function greet(name: string): string {
  return `Hello, ${name}`;
}

// ...compiles to this JavaScript
function greet(name) {
  return `Hello, ${name}`;
}

The types disappear at runtime. They exist to help you, your IDE, and your teammates understand and validate the code. For a detailed look at what changes when moving from plain JavaScript, see the JavaScript vs TypeScript variables comparison. Research backs this up: a 2017 study published at ICSE (Gao et al., "To Type or Not to Type") found that about 15% of publicly reported JavaScript bugs could have been detected by TypeScript's type system. Airbnb's engineering team separately reported that 38% of production bugs they analyzed were preventable with static types.

Use interface for extendable objects and declaration merging. Use type for unions, intersections, and primitives. For plain objects, either works—pick one convention and be consistent.

Both can define object shapes. Here's when to pick each:

// Interface: extendable
interface User {
  id: number;
  name: string;
}

interface Admin extends User {
  permissions: string[];
}

// Type: flexible composition
type Status = 'active' | 'inactive' | 'pending';
type Response<T> = { ok: true; data: T } | { ok: false; error: string };

The practical rule: Use interface for objects you might extend. Use type for everything else. Or just pick one and be consistent--the difference rarely matters. The JavaScript vs TypeScript interfaces comparison explores this topic in depth.

Use typeof, in, instanceof, equality checks, or type guard functions (x is T) to narrow broad types. TypeScript tracks what you've checked and refines the type within each code block.

Within a code block, TypeScript tracks what you've already checked and refines the type:

function process(value: string | number | null) {
  // Here: value is string | number | null

  if (value === null) {
    return; // Early return
  }
  // Here: value is string | number (null eliminated)

  if (typeof value === 'string') {
    console.log(value.toUpperCase()); // value is string
  } else {
    console.log(value.toFixed(2)); // value is number
  }
}

Narrowing techniques

Type guard functions

For complex validation, write a type guard:

interface User {
  id: number;
  name: string;
}

function isUser(x: unknown): x is User {
  if (typeof x !== 'object' || x === null) return false;
  if (!('id' in x) || typeof x.id !== 'number') return false;
  if (!('name' in x) || typeof x.name !== 'string') return false;
  return true;
}

// Usage
function handleData(data: unknown) {
  if (isUser(data)) {
    console.log(data.name); // TypeScript knows it's User
  }
}

For production apps, consider libraries like Zod or ArkType that generate type guards from schemas. They handle edge cases and provide better error messages. For a side-by-side look at how TypeScript's type system compares to plain JavaScript, see the JavaScript vs TypeScript types comparison.

Generics let you write code that works with any type while preserving type information:

// Without generics: loses type info
function firstAny(arr: any[]): any {
  return arr[0];
}

// With generics: preserves type info
function first<T>(arr: T[]): T | undefined {
  return arr[0];
}

const num = first([1, 2, 3]);      // type: number | undefined
const str = first(['a', 'b']);    // type: string | undefined

Generic constraints

Use extends to constrain what types are allowed:

// T must have a length property
function logLength<T extends { length: number }>(item: T): void {
  console.log(item.length);
}

logLength('hello');     // OK: string has length
logLength([1, 2, 3]);   // OK: array has length
logLength(42);          // Error: number doesn't have length

The keyof + extends pattern

This is the most common generic pattern--safely accessing object properties. The JavaScript vs TypeScript functions comparison shows how generics improve function signatures:

function getProperty<T, K extends keyof T>(obj: T, key: K): T[K] {
  return obj[key];
}

const user = { id: 1, name: 'Alice' };
getProperty(user, 'name');  // OK, returns string
getProperty(user, 'foo');   // Error: 'foo' not in keyof User

Built-in utility types save you from writing repetitive type definitions:

Essential utility types

interface User {
  id: number;
  name: string;
  email: string;
  password: string;
}

// For updates: all optional except you can't change id
type UserUpdate = Partial<Omit<User, 'id'>>;

// For public display: no password
type PublicUser = Omit<User, 'password'>;

// For creating: required fields only
type CreateUser = Pick<User, 'name' | 'email' | 'password'>;

A discriminated union uses a common property (the "discriminant") to tell types apart:

type ApiResponse<T> =
  | { status: 'success'; data: T }
  | { status: 'error'; error: string }
  | { status: 'loading' };

function handleResponse(res: ApiResponse<User>) {
  switch (res.status) {
    case 'success':
      console.log(res.data.name); // data exists here
      break;
    case 'error':
      console.log(res.error); // error exists here
      break;
    case 'loading':
      console.log('Loading...');
      break;
  }
}

Exhaustive checking with never

Ensure you handle all cases:

function assertNever(x: never): never {
  throw new Error(`Unexpected value: ${x}`);
}

function handleResponse(res: ApiResponse<User>) {
  switch (res.status) {
    case 'success': return res.data;
    case 'error': throw new Error(res.error);
    case 'loading': return null;
    default:
      return assertNever(res); // Error if a case is missed
  }
}

satisfies (TypeScript 4.9+) validates a value matches a type while keeping precise inference:

// Without satisfies: type widened to Record<string, string>
const routes1: Record<string, string> = {
  home: '/',
  about: '/about',
};
routes1.home; // type: string

// With satisfies: type is precise
const routes2 = {
  home: '/',
  about: '/about',
} satisfies Record<string, string>;
routes2.home; // type: '/' (literal)

// And you still get validation
const routes3 = {
  home: '/',
  about: 123, // Error: number not assignable to string
} satisfies Record<string, string>;

Use satisfies when: You want to validate a shape but preserve the exact inferred types (especially literal types).

TS2322: Type 'X' is not assignable to type 'Y'

You're assigning a value that doesn't match the expected type.

// Error
let name: string = 42;

// Fixes: correct the type or the value
let name: string = 'Alice';
let count: number = 42;

TS2339: Property 'X' does not exist on type 'Y'

You're accessing a property that TypeScript doesn't know exists.

// Error
const obj: object = { name: 'Alice' };
console.log(obj.name); // Property 'name' does not exist on 'object'

// Fix: use a more specific type
const obj: { name: string } = { name: 'Alice' };
console.log(obj.name); // OK

TS18046: 'X' is of type 'unknown'

You're using an unknown value without narrowing it first.

// Error
function process(data: unknown) {
  console.log(data.name); // Error: unknown
}

// Fix: narrow first
function process(data: unknown) {
  if (typeof data === 'object' && data !== null && 'name' in data) {
    console.log((data as { name: string }).name); // OK
  }
}

TS2345: Argument of type 'X' is not assignable to parameter of type 'Y'

Function argument doesn't match parameter type.

// Error
function greet(name: string) { ... }
greet(42); // Error: number not assignable to string

// Fix: pass correct type
greet('Alice');

TS7006: Parameter 'x' implicitly has an 'any' type

You have strict or noImplicitAny enabled and a parameter has no type annotation.

// Error (with noImplicitAny)
function double(n) {  // Parameter 'n' implicitly has 'any' type
  return n * 2;
}

// Fix: add type annotation
function double(n: number) {
  return n * 2;
}

This is the most common error when enabling strict mode on an existing project. Fix by adding explicit types to function parameters.

• TypeScript Handbook
• TypeScript: Narrowing
• TypeScript: Generics
• TypeScript: Utility Types
• TypeScript: satisfies operator
• TypeScript Error Codes Reference

For dedicated cheatsheets on generics, utility types, type narrowing, and the satisfies operator, see the TypeScript reference page.