Generics

Some code does the same job whatever it is given. Take the first item of a list. Group records by a field. Cache a result. The logic does not care whether the items are employees or expenses.

Written without generics, that code has to accept any, and the type of the items is thrown away. Generics let a function stay general while remembering what it was given, so the caller gets a specific type back.

// The type of the items is discarded
const anyEmployees: any[] = loadEmployees();

anyEmployees[0].nmae;              // No error. undefined at run time
anyEmployees[0].toFixed(2);        // No error. Throws at run time

// Array<Employee> is the same array, with the element type kept
const employees: Array<Employee> = loadEmployees();

employees[0].nmae;                 // Error: no such property on Employee
employees[0].name.toUpperCase();   // Checked, and the editor can complete it

• Array is generic: it takes the element type as a parameter. Array<Employee> and Employee[] mean exactly the same thing, and the bracket form is the usual way to write it.
• With any[], indexing gives you any. Every property and method is permitted, so a misspelled name is accepted and fails later.
• With Array<Employee>, indexing gives you an Employee. The typo is an error where you wrote it, and the editor can offer the real property names.
• This is what preserving type information means, and it is why generics exist. The array code is identical in both cases; only what the checker knows about the contents differs.

function firstOrUndefined<T>(items: T[]): T | undefined {
  return items.length > 0 ? items[0] : undefined;
}

const employee = firstOrUndefined(employees);   // Employee | undefined
const expense = firstOrUndefined(expenses);     // Expense | undefined

if (employee) {
  console.log(employee.department);             // known to be an Employee
}

// Two type parameters, used together
function pluck<TItem, TKey extends keyof TItem>(items: TItem[], key: TKey): TItem[TKey][] {
  return items.map((item) => item[key]);
}

const names = pluck(employees, "name");         // string[]
const amounts = pluck(expenses, "amount");      // number[]
const wrong = pluck(employees, "nmae");         // Error: not a key of Employee

• The <T> after the name declares a type parameter — a placeholder for a type that the caller decides.
• T is used in both the parameter and the return type, and that connection is the whole mechanism: whatever type goes in comes back out.
• Nothing is passed explicitly at the call sites. The type is inferred from the argument, so employees gives T = Employee.
• The return is T | undefined because an empty array has no first item. The caller has to check, which is the honest signature for this function.
• pluck has two parameters. keyof TItem is the union of that type's property names, so the second argument can only be a real property — "nmae" fails immediately.
• TItem[TKey] is the type of that property, so the return type follows the key you passed: names is string[] and amounts is number[]. One function, precise types for both.

// Without the constraint, item.id would be an error: T might not have one
function indexById<T extends { id: string }>(items: T[]): Map<string, T> {
  const byId = new Map<string, T>();

  for (const item of items) {
    byId.set(item.id, item);
  }

  return byId;
}

const employeesById = indexById(employees);   // Map<string, Employee>
const found = employeesById.get("E-00417");   // Employee | undefined

// Rejected at compile time: no id property
indexById([{ label: "Travel" }, { label: "Equipment" }]);

• T extends { id: string } says: whatever T is, it has a string id. That is the minimum this function needs.
• Inside the body, item.id is now allowed. Without the constraint the checker would refuse, because an unconstrained T could be a number.
• The constraint does not narrow the return type. Passing employees still gives Map<string, Employee>, with every other property intact — the function asked for the minimum and kept the rest.
• Map is generic in two parameters, the key type and the value type, so get returns Employee | undefined. The undefined is correct: the id might not be there.
• The last line fails because those objects have no id. The error names the missing property, which points straight at the cause.