Interfaces and Type Aliases

Most of the values in an application are objects with a known shape. An employee has an id, a name and a department. An expense has an amount and a status.

Writing that shape down once gives you two things: the checker can verify every place the object is built or read, and the next person has a definition to look at instead of guessing from the code that happens to use it.

interface Employee {
  readonly id: string;
  name: string;
  department: string;
  startDate: string;
  managerName?: string;
  isActive: boolean;
}

const priya: Employee = {
  id: "E-00417",
  name: "Priya Raman",
  department: "Finance",
  startDate: "2021-04-12",
  isActive: true,
};

priya.department = "Payroll";   // fine
priya.id = "E-00418";           // Error: id is readonly

function describe(employee: Employee): string {
  return employee.name + ", " + employee.department;
}

• An interface lists the properties and their types. It describes a shape; it creates nothing at run time.
• readonly on id says this value is set when the record is created and never changed afterwards. Attempting it is a compile error.
• The question mark on managerName makes it optional. Its type becomes string | undefined, so the checker will not let you use it without handling the absence.
• priya is accepted even though managerName is missing, because it is optional. Leave out department and it is an error naming the missing property.
• Adding a property the interface does not list is also an error when assigning an object literal directly like this. That catches typos such as departmnet, which in plain JavaScript would silently create a new property.
• Using Employee as a parameter type means describe works with any object of that shape, from anywhere in the application.

type ExpenseStatus = "draft" | "submitted" | "approved" | "rejected";

interface Expense {
  readonly id: string;
  description: string;
  amount: number;
  status: ExpenseStatus;
  rejectionReason?: string;
}

function statusLabel(status: ExpenseStatus): string {
  switch (status) {
    case "draft":
      return "Not yet submitted";
    case "submitted":
      return "Awaiting approval";
    case "approved":
      return "Approved for payment";
    case "rejected":
      return "Rejected";
  }
}

function describeExpense(expense: Expense): string {
  if (expense.status === "rejected" && expense.rejectionReason) {
    return "Rejected: " + expense.rejectionReason;
  }

  return statusLabel(expense.status);
}

• ExpenseStatus is a union of four exact strings. Assigning "aproved" is a compile error, which is a typo that otherwise produces a row matching no filter and no visible failure.
• Inside the switch, each case narrows status to that one literal. The checker follows the control flow and knows which value you are dealing with in each branch.
• There is no default, and it still satisfies the string return type, because the four cases cover every possible value. Add a fifth status to the union later and this function becomes an error — which is the behaviour you want, because it lists the places that need updating.
• rejectionReason is optional, and the check for it is not defensive padding: without it the property is string | undefined and cannot be concatenated safely under strict mode.
• Checking status === "rejected" first documents the pairing between the status and the reason. A discriminated union can enforce that pairing outright, which is worth reaching for once several fields depend on a status.

// A named function type, so callbacks are described in one place
type ExpenseFilter = (expense: Expense) => boolean;

const isOverLimit: ExpenseFilter = (expense) => expense.amount > 50;

function countMatching(expenses: Expense[], matches: ExpenseFilter): number {
  return expenses.filter(matches).length;
}

// Methods can be described inside an interface too
interface ExpenseStore {
  getAll(): Expense[];
  add(expense: Expense): void;
  onChange(handler: (expenses: Expense[]) => void): void;
}

• A function type gives the parameters and, after the arrow, the return type. This one takes an Expense and answers true or false.
• Because isOverLimit is annotated with that type, the parameter needs no annotation — the checker knows what it must be. This is contextual typing, and it is why callbacks passed to filter or map rarely need annotations.
• countMatching accepts any function of that shape. The name ExpenseFilter makes the parameter self-describing, which an inline type does not.
• Inside an interface, a method is written as a name with parameters and a return type. void means it returns nothing useful.
• onChange takes a function as its argument, and its type is written inline. Nesting function types more than one level deep quickly becomes unreadable — name them at that point.