Defining and Using Interfaces and Type Aliases

What are Object Types?

In TypeScript, we use object types to describe the structure of an object—what properties it has and what types those properties should be. This is the essence of "structural typing," a core concept in TypeScript. Unlike nominal typing (found in languages like Java or C#) where a type is defined by its explicit declaration name, structural typing checks for compatibility based on the object's shape. If two objects have the same structure of properties and types, they are considered compatible, regardless of what they are named.

The two primary ways to give a name to an object type are with an interface or a type alias.

As you saw, both interface and type can describe the same simple object. This overlap is a common source of confusion, but by the end of this lesson, you'll have a clear framework for understanding their distinct roles.

Property Modifiers: Optional and Read-only

Before we dive into the differences, let's cover two useful modifiers you can apply to properties within any object type. These help you define shapes with more precision.

Here's an example combining these concepts, which is typical for defining data models in Angular:

interface User {
  readonly id: number; // Cannot be changed after creation
  name: string;
  email?: string;      // Optional property
}

const user: User = {
  id: 1,
  name: 'Jane Doe',
};

user.name = 'Jane Smith'; // OK
// user.id = 2; // Error: Cannot assign to 'id' because it is a read-only property.

Similarities and Differences: The Core of the Matter

While interface and type can seem interchangeable at first, they have crucial differences that influence when you should use them. We'll explore these differences, starting with a video that gives a fantastic overview.

Let's solidify the two most important distinctions you just saw.

1. Declaration Merging: "Open" vs. "Closed"

As the video highlighted, interfaces are "open," meaning you can define the same interface multiple times, and TypeScript will merge them into a single definition. Type aliases are "closed"; you cannot declare the same type alias twice in the same scope.

This is arguably the most significant difference.

This feature of interfaces is called declaration merging. It's powerful for augmenting existing interfaces from external libraries or built-in types (like the browser's Window object). However, it can also lead to unexpected behavior if you accidentally redefine an interface.

2. Flexibility: Any Type vs. Object Shapes

The other major distinction is flexibility. A type alias, true to its name, can create a new name for any type. An interface can only describe the shape of an object or a function.

// Type aliases can do all of this:
type UserID = string; // Alias for a primitive
type Status = "pending" | "complete" | "failed"; // Union type
type Point = [number, number]; // Tuple type
type UserWithStatus = User & { status: Status }; // Intersection

// Interfaces are primarily for object shapes:
interface Admin extends User {
  permissions: string[];
}

The ability of type aliases to create unions is especially important and frequently used in modern TypeScript and Angular development to model states or variations of data.

Which One Should You Use?

So, with these differences in mind, how do you choose? There are two popular schools of thought, and it's valuable to understand both.

To summarize the two main viewpoints:

1. Interface First (Classic Recommendation): Use interface to define all object shapes. Only use type when you need features interfaces don't have, like unions. This is the official TypeScript recommendation and is common in older codebases and many of Angular's own APIs.

2. Type First (Modern Recommendation): Use type for everything by default. Its explicitness (no declaration merging) prevents bugs, and its flexibility is more powerful. Only use interface when you specifically need declaration merging or want to use extends for object inheritance hierarchies.

My Recommendation for You:

For your work in Angular, you will encounter both. Being comfortable with both is essential. For your own application code, a pragmatic approach is best:

• Use interface with extends when defining core data models that have a clear inheritance structure (e.g., BaseRecord, UserRecord extends BaseRecord). This is idiomatic, clean, and leverages the performance characteristics you read about.
• Use type for everything else, especially for defining props for UI components, states that can be a union of different shapes, or simple aliases for primitives.

Consistency within your team and project is the most important factor.

Conclusion

In this lesson, we've unpacked the two ways TypeScript allows us to describe the shape of data. You now have a mental model to distinguish between them and make an informed choice.

Here are the key takeaways:

• Core Function: Both interface and type can define the shape of an object.
• Key Differences:
  • Extensibility: interface supports declaration merging (it's "open"), while type does not (it's "closed").
  • Flexibility: type can alias any type (primitives, unions, tuples), while interface is for object/function shapes.
  • Syntax: interface uses extends for inheritance; type uses & (intersection) to combine shapes.
• Practical Choice: The choice depends on convention and need. Using interface for object hierarchies and type for more flexible definitions like component props or union states is a robust and modern strategy.

Now that you can define the shape of your data, the next logical step is to write code that can work with any shape. In our next lesson, we will explore generics, a powerful feature that allows us to write reusable, type-safe functions and classes that operate on a variety of types without sacrificing type safety.