TypeScript Interfaces, Type Aliases and Union Types

How would you represent a customer-support timeline? Tickets get opened, replied to and closed, and each event carries different data: an opened event has a subject, a reply has an agent and a response time, a closure has a resolution. A beginner's first draft is one big object with every field marked optional, and then every piece of code that reads it has to guess which fields are present. TypeScript lets you say it properly: an event is one of three precise shapes, and the compiler checks that you handle each one.

Interfaces and type aliases: two ways to name a shape

An interface describes the shape of an object: its property names, their types, which are optional (?) and which cannot be reassigned (readonly). A type alias gives a name to any type at all, including unions, tuples and primitives. For plain object shapes the two are almost interchangeable, so teams pick a convention. A common one is interfaces for object shapes that other code might extend, type aliases for everything else.

Optional properties and unions interact in a way worth knowing. note?: string means the property may be missing entirely, and reading it gives string | undefined. A property declared note: string | undefined must be present but may hold undefined. Most of the time you want the first form for data that genuinely may be absent. Prefer separate interfaces over a pile of optionals when the optional fields only make sense together, because the union lets the compiler enforce that.

A discriminated union for the support desk

A union type A | B | C means a value is one of those types. When every member has a property with a unique literal value, here kind, TypeScript can tell the members apart by checking that property. That is called a discriminated union, and it is one of the most useful patterns in the language.

// desk.ts - events on a support desk, as a discriminated union
type Priority = "low" | "normal" | "urgent";

interface TicketBase {
  readonly id: number;
  customer: string;
  priority: Priority;
  note?: string;
}

interface Opened extends TicketBase {
  kind: "opened";
  subject: string;
}
interface Replied extends TicketBase {
  kind: "replied";
  agent: string;
  minutesToReply: number;
}
interface Closed extends TicketBase {
  kind: "closed";
  resolution: "fixed" | "wont-fix" | "duplicate";
}

type TicketEvent = Opened | Replied | Closed;

function summarise(event: TicketEvent): string {
  switch (event.kind) {
    case "opened":
      return `#${event.id} opened by ${event.customer}: ${event.subject}`;
    case "replied":
      return `#${event.id} answered by ${event.agent} after ${event.minutesToReply} min`;
    case "closed":
      return `#${event.id} closed (${event.resolution})`;
    default: {
      const unreachable: never = event;
      return unreachable;
    }
  }
}

const feed: TicketEvent[] = [
  { kind: "opened", id: 41, customer: "Okafor Ltd", priority: "urgent", subject: "Cannot export invoices" },
  { kind: "replied", id: 41, customer: "Okafor Ltd", priority: "urgent", agent: "Priya", minutesToReply: 12 },
  { kind: "closed", id: 41, customer: "Okafor Ltd", priority: "urgent", resolution: "fixed" },
];

for (const event of feed) console.log(summarise(event));

const urgentCount = feed.filter((e) => e.priority === "urgent").length;
console.log("urgent events:", urgentCount);

type Audited = TicketEvent & { auditedBy: string };
const audited: Audited = { ...feed[2], auditedBy: "Lena" };
console.log(audited.kind, audited.auditedBy);

#41 opened by Okafor Ltd: Cannot export invoices
#41 answered by Priya after 12 min
#41 closed (fixed)
urgent events: 3
closed Lena

Inside each case, TypeScript narrows event to the matching member, so event.subject is allowed under "opened" and a typo or the wrong property is an error. Properties that exist on every member, like priority, can be used without narrowing. The default branch assigns event to a variable of type never: if every case is handled, nothing is left, so it compiles. This is an exhaustiveness check. Add a fourth event type later and every switch that forgot it stops compiling, which turns "did I update everything?" into a compiler job.

The & operator builds an intersection: TicketEvent & { auditedBy: string } has everything from the event and the extra field. Use unions when a value is one of several shapes, and intersections when a value must satisfy several shapes at once. Note that the example runs with node --experimental-strip-types because it uses only type syntax.

What the compiler says when you break the model

Suppose the desk adds an "escalated" event but nobody updates the switch, and a developer also makes a few typical slips. This is wrong on purpose; the messages are real TypeScript 5.9 output for the lines described.

interface Escalated extends TicketBase { kind: "escalated"; to: string }
type TicketEvent = Opened | Replied | Closed | Escalated;

// in summarise(): the default branch now fails           (1)
const t: Opened = { kind: "opened", id: 1, customer: "x", priority: "urgent", subject: "s" };
t.id = 2;                                                  // (2)
t.priority = "high";                                       // (3)
function agentOf(e: TicketEvent) { return e.agent; }      // (4)
const u: TicketEvent = { kind: "opened", id: 1, customer: "x", priority: "low" };   // (5)

(1) Type 'Escalated' is not assignable to type 'never'.
(2) Cannot assign to 'id' because it is a read-only property.
(3) Type '"high"' is not assignable to type 'Priority'.
(4) Property 'agent' does not exist on type 'TicketEvent'.
      Property 'agent' does not exist on type 'Opened'.
(5) Property 'subject' is missing in type '{ kind: "opened"; id: number; customer: string; priority: "low"; }' but required in type 'Opened'.

Common mistakes and the errors they produce

• One big object with every field optional. Every consumer has to guess which fields exist, and you get 'agent' is possibly 'undefined' everywhere. Use a union of precise shapes.
• A discriminant typed as `string`. If kind is string instead of a literal such as "opened", narrowing does nothing and you get Property 'subject' does not exist on type. Make it a literal type.
• Reading a member-only property without narrowing. e.agent on the whole union gives Property 'agent' does not exist on type 'TicketEvent'. Check e.kind first.
• Mixing up `|` and `&`. A & B demands both shapes at once; two object types with conflicting property types can produce never. Reach for & only when you mean "both".
• Assuming `readonly` freezes at runtime. It is a compile-time check only, and it is shallow: a readonly array property can still be pushed to unless you use readonly string[].
• Relying on declaration merging by accident. Two interfaces with the same name are silently merged. If that surprises you, use a type alias, which reports a duplicate.

How this shows up in real projects and interviews

Discriminated unions show up wherever data has distinct states: API results ({ ok: true, data } | { ok: false, error }), UI loading states, reducer actions in Redux or React's useReducer, and event buses. They replace flags like isLoading plus error plus data that can contradict each other. Interviewers often ask "interface or type?" and want a reasoned convention, not a rule; a good answer mentions extension, unions and merging. See how this feeds into component props in React components and props. Next, make this kind of code reusable across types with generics.