Interfaces are one of TypeScript’s core features, allowing developers to flexibly and expressively enforce constraints on their code to reduce bugs and improve code readability. Let’s dive into exploring interfaces’ characteristics and how we might better leverage them in our programs.
What are interfaces?
First, a little background. Interfaces are a way for developers to name a type for later reference in their programs. For example, a public library’s management software might have a
Book interface for data representing books in the library’s collection:
With it, we can ensure that book data in the program contains the essential information of title, author, and ISBN. If it doesn’t, the TypeScript compiler will throw an error:
Interfaces vs. types
If you’ve written TypeScript code before, you might be familiar with type aliases, another common way to name a type, and you might be asking, “Why use interfaces over types or vice versa?”
The primary difference is that interfaces can be reopened for adding additional properties (via declaration merging) in different parts of your program, while type aliases cannot. Let’s look at how to take advantage of declaration merging, as well as some cases of when you might want to.
Expanding interfaces in TypeScript
Option 1: Declaration merging
As noted above, interfaces can be reopened to add new properties and expand the definition of the type. Here is a nonsensical example to illustrate this capability:
Of course, it’s not likely that the same interface would be reopened nearby like this. It would be clearer to simply define it in a single statement:
So, when would you want to expand an interface in different parts of your program? Let’s take a look at a real-world use case.
Declaration merging to wrangle disparate user preferences
Suppose you are writing a React application, and you need some pages that will allow the user to configure information such as their profile, notification preferences, and accessibility settings.
For clarity and user experience, you’ve split up these three concerns into three separate pages where the source code will be in three files:
From an application architecture perspective, it would be nice if all of the user’s preferences were contained in a single object that adheres to an interface we’ll call
Preferences. This way, you can easily load and save the preferences object with your backend API with just one or two endpoints rather than several.
The next question is: “Where should the
Preferences interface be defined?” You could put the interface in its own file,
import it into the three pages — or, you could take advantage of declaration merging and have each page define only the properties of
Preferences that it cares about, like so:
In the end, the
Preferences interface will resolve to fully contain all the properties, as desired:
And the UI code is now co-located with only the properties of
Preferences it is responsible for managing, making the program easier to understand and maintain. Nice!
Option 2: Extending interfaces in TypeScript
Another way to expand interfaces in TypeScript is to mix one or more of them into a new interface.
This probably looks familiar to object-oriented programmers. However, interfaces offer a key feature that is not typically found in traditional object-oriented programming: multiple inheritance.
Multiple inheritance allows us to combine behaviors and properties of multiple interfaces into a single interface. Let’s look at a use case for when you might want to do this.
Extending interfaces to form a type-safe global state store
Suppose that you’re building an application that enables users to keep track of their to-do lists and their daily schedules in one place. You’ll have some different UI components for tracking each of those tasks:
Now that you’ve created the basic interfaces for keeping track of your two pieces of state, you would like a single interface that represents the state of the entire application. We can use the
extends keyword to create such an interface. We’ll also add a
modified field so that we know when our state was last updated:
Now you can use the
AppState interface to ensure that the application is properly handling the state.
While re-opening interfaces is not possible with type aliases, this approach of extending types is, but with some subtle differences in syntax. Here’s the equivalent example adapted to use
type instead of
There are a few different ways to extend object-like types with interfaces in TypeScript, and, in some cases, you may be able to use type aliases. In those cases, even the official docs say they are mostly interchangeable, at which point it’s down to style, preference, organization, habit, etc. But if you’d like to declare different properties on the same type in different parts of your program, use interfaces.