Structuring TypeScript: Interfaces, Type Aliases, Enums, and Object Types

You've learned TypeScript's primitive types and the basics of type inference here. Now it's time to model real-world data — users, orders, API responses, configuration objects. That's where interfaces, type aliases, and enums come in.

These three features are what make TypeScript genuinely powerful for building applications. Let's dig in.

Object Types: Describing the Shape of Data

Before we get to interfaces, let's understand object types. When you want to describe the structure of an object, you define what properties it has and what types those properties are:

// Inline object type annotation
function displayUser(user: { name: string; age: number; email: string }): void {
  console.log(`${user.name} (${user.age}) — ${user.email}`);
}

This works, but it's messy to repeat everywhere. That's why we use type aliases and interfaces to name and reuse these shapes.

Type Aliases: Naming a Type

A type alias gives a name to any type — primitives, unions, objects, or combinations:

// Alias for a primitive union
type ID = string | number;

// Alias for an object shape
type User = {
  id: ID;
  name: string;
  age: number;
  email: string;
};

// Now use it anywhere
const user: User = {
  id: 1,
  name: "Ramesh",
  age: 31,
  email: "ramesh@example.com",
};

function getUser(id: ID): User {
  // ... fetch user logic
}

Type aliases are flexible — they can represent almost anything.

Interfaces: Defining Object Contracts

An interface is specifically designed to describe the shape of an object. Syntax is slightly different:

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

const user: User = {
  id: 1,
  name: "Ramesh",
  age: 31,
  email: "ramesh@example.com",
};

Optional and Readonly Properties

Properties can be marked as optional (?) or read-only (readonly):

interface UserProfile {
  readonly id: number;      // Can't be changed after creation
  name: string;
  age?: number;             // Optional — may or may not be present
  bio?: string;             // Optional
}

const profile: UserProfile = { id: 101, name: "Ramesh" };
profile.id = 999;           // ❌ Error: Cannot assign to 'id' (readonly)
profile.age = 31;           // ✅ Fine, optional doesn't mean immutable

Extending Interfaces

Interfaces support inheritance — you can build on existing ones:

interface Animal {
  name: string;
  sound(): string;
}

interface Dog extends Animal {
  breed: string;
  fetch(): void;
}

const myDog: Dog = {
  name: "Bruno",
  breed: "Labrador",
  sound: () => "Woof!",
  fetch: () => console.log("Fetching..."),
};

This is great for modelling hierarchical data (e.g. AdminUser extends User).

`interface` vs `type`: When to Use Which

This is one of TypeScript's most debated questions. Here's a practical answer:

Feature	`interface`	`type`
Object shapes	✅	✅
Primitives/unions	❌	✅
Extending/inheriting	`extends` keyword	Intersection (`&`)
Declaration merging	✅	❌
Use with classes	✅ Preferred	Works

// Extending with interface
interface Animal { name: string; }
interface Dog extends Animal { breed: string; }

// Extending with type (using intersection)
type Animal = { name: string; };
type Dog = Animal & { breed: string; };

The honest answer:

Use interface for objects that represent real-world entities (users, products, components)
Use type for unions, intersections, utility combinations, and when you need to alias primitive types

In most modern TypeScript codebases, both work. Just be consistent within a project.

Enums: Named Constants That Make Sense

An enum is a set of named constant values. Instead of using magic strings or numbers scattered across your code, you define them once:

Numeric Enums

enum Direction {
  Up,    // 0
  Down,  // 1
  Left,  // 2
  Right, // 3
}

function move(dir: Direction): void {
  console.log(`Moving in direction: ${dir}`);
}

move(Direction.Up);    // ✅ Clean, readable
move(0);               // ✅ Also works (but less clear)
move("Up");            // ❌ Error

Values auto-increment from 0. You can override the starting number:

enum StatusCode {
  OK = 200,
  NotFound = 404,
  ServerError = 500,
}

console.log(StatusCode.OK); // 200

String Enums (More Common in Practice)

enum OrderStatus {
  Pending = "PENDING",
  Processing = "PROCESSING",
  Shipped = "SHIPPED",
  Delivered = "DELIVERED",
  Cancelled = "CANCELLED",
}

function updateOrderStatus(orderId: number, status: OrderStatus): void {
  console.log(`Order ${orderId} is now: ${status}`);
}

updateOrderStatus(1001, OrderStatus.Shipped);
// Output: Order 1001 is now: SHIPPED

String enums are preferred because the values are human-readable in logs, APIs, and debugging.

When to Use Enums vs Union Types

// Union type approach
type OrderStatus = "PENDING" | "SHIPPED" | "DELIVERED";

// Enum approach
enum OrderStatus {
  Pending = "PENDING",
  Shipped = "SHIPPED",
  Delivered = "DELIVERED",
}

Use union types when the values are simple and stable. Use enums when you need a named, reusable group of constants — especially when the values are used across many files.

Putting It All Together: A Real Example

Here's how interfaces, type aliases, and enums work together in a realistic scenario:

// Enum for user roles
enum UserRole {
  Admin = "ADMIN",
  Editor = "EDITOR",
  Viewer = "VIEWER",
}

// Base interface for all users
interface BaseUser {
  readonly id: number;
  name: string;
  email: string;
  createdAt: Date;
}

// Extended interface with role
interface AppUser extends BaseUser {
  role: UserRole;
  lastLogin?: Date;
}

// Type alias for API response shape
type ApiResponse<T> = {
  success: boolean;
  data: T;
  error?: string;
};

// Function using all of the above
function createUser(name: string, email: string, role: UserRole): ApiResponse<AppUser> {
  const newUser: AppUser = {
    id: Math.random(),
    name,
    email,
    role,
    createdAt: new Date(),
  };

  return {
    success: true,
    data: newUser,
  };
}

const result = createUser("Ramesh", "ramesh@example.com", UserRole.Admin);
console.log(result.data.role); // "ADMIN"

Notice how the types tell a clear story. You don't need to read the function implementation to understand what it takes and what it returns.

Common Mistakes to Avoid

Mistake 1: Over-nesting object types

// ❌ Hard to read and reuse
interface Order {
  user: {
    id: number;
    address: {
      street: string;
      city: string;
    };
  };
}

// ✅ Break it out into named types
interface Address {
  street: string;
  city: string;
}

interface OrderUser {
  id: number;
  address: Address;
}

interface Order {
  user: OrderUser;
}

Mistake 2: Numeric enums in APIs

// ❌ Numeric enum values in API responses are confusing
enum Status { Active, Inactive } // 0, 1 in JSON — meaningless without context

// ✅ String enums are self-documenting
enum Status { Active = "ACTIVE", Inactive = "INACTIVE" }

Summary

Here's what to remember from this post:

Object types describe the shape of an object inline
Type aliases (type) name any type — great for unions, intersections, and flexibility
Interfaces (interface) define object contracts — great for classes, extension, and real-world entities
Use readonly for immutable properties, ? for optional ones
Enums group related constants — prefer string enums for readability
Combine all three to model complex, real-world data clearly

You've completed the TypeScript Beginners Series. You now understand the full foundation: types, inference, arrays, tuples, unions, interfaces, aliases, and enums. That's everything you need to start writing real TypeScript confidently.

Found this helpful? Follow for the rest of the series. Questions or corrections? Drop them in the comments.

推荐订阅源

DEV Community