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

A developer explains TypeScript's interfaces, type aliases, enums, and object types for modeling real-world data. The post covers how to define and reuse object shapes, optional and readonly properties, inheritance with interfaces, and when to use interfaces versus type aliases. Enums are introduced as a way to define named constant values.

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. 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. 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. 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", }; 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 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: interface for objects that represent real-world entities users, products, components type for unions, intersections, utility combinations, and when you need to alias primitive typesIn most modern TypeScript codebases, both work. Just be consistent within a project. An enum is a set of named constant values. Instead of using magic strings or numbers scattered across your code, you define them once: 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 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. // 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. 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. 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" } Here's what to remember from this post: type name any type — great for unions, intersections, and flexibility interface define object contracts — great for classes, extension, and real-world entities readonly for immutable properties, ? for optional ones 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.