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 flexibilityinterface
) define object contracts — great for classes, extension, and real-world entitiesreadonly
for immutable properties, ?
for optional onesYou'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.