The difference between types and interfaces in TypeScript used to be more clear, but with the latest versions of TypeScript, they’re becoming more similar.
Interfaces are basically a way to describe data shapes, for example, an object.
Type is a definition of a type of data, for example, a union, primitive, intersection, tuple, or any other type.
some Differences in some topics:
1-Functions:
Both can be used to describe the shape of an object or a function signature. But the syntax differs.
Interface
interface Point {
x: number;
y: number;
}
interface SetPoint {
(x: number, y: number): void;
}
Type
type Point = {
x: number;
y: number;
};
type SetPoint = (x: number, y: number) => void;
2-Declaration merging
Unlike a type alias, an interface can be defined multiple times, and will be treated as a single interface (with members of all declarations being merged).
3-Extends and Implements:
In TypeScript, we can easily extend and implement interfaces. This is not possible with types though.
Interfaces in TypeScript can extend classes, this is a very awesome concept that helps a lot in a more object-oriented way of programming. We can also create classes implementing interfaces.
4-Intersection (&):
Intersection allows us to combine multiple types into a single one type. To create an intersection type, we have to use the (&) keyword,
type Name = {
name: “string”
};
type Age = {
age: number
};
type Person = Name & Age;
The nice thing here is that we can create a new intersection type combining two interfaces, for example, but not the other way around. We cannot create an interface combining two types, because it doesn’t work,
interface Name {
name: “string”
};
interface Age {
age: number
};
type Person = Name & Age;
5-Union (|):
Union types allow us to create a new type that can have a value of one or a few more types. To create a union type, we have to use the | keyword,
type Man = {
name: “string”
};
type Woman = {
name: “string”
};
type Person = Man | Woman;
Similar to intersections, we can create a new union type combining two interfaces, for example, but not the other way around:
interface Man {
name: “string”
};
interface Woman {
name: “string”
};
type Person = Man | Woman;
**Summary of Type Aliases vs Interfaces
Your mileage may differ, but wherever possible, I stick to type aliases for their flexibility and simpler syntax. That is, I pick type aliases except I specifically need features from an interface.
For the most part, you can also decide based on your personal preference, but stay consistent with your choice — at least in a single given project.
For completeness, I must add that in performance critical types, interface comparison checks can be faster than type aliases. I’m yet to find this to be an issue.
