Ughh, type vs interface

I’ve hit type vs interface confusion multiple times and read dozens of posts finally spent more time today to understand and make some sense out of it. Thought to make a notes of differences based on my understanding.

Type is short for type alias in typescript.
Usually type and interfaces are used interchangeably but there are subtle differences.
Before TS 4.2 when complex type aliases were created and if error occurs the compiler error messages used to be misleading where the exact error occurred compared to interfaces, but it’s fixed in TS version >4.2.
People tend to use interface for objects since it’s more natural while reading compared to type aliases which creates confusion.

1// seems more like a variable and creates confusion 
2type Color = {
3    primary100: string
4    primary200: string
5}
6
7// seems more natural that it is defining type
8interface Color {
9    primary100: string
10    primary200: string
11}

Interfaces are easy to merge.
This is is useful for adding missing type information on 3rd party libraries. If you are authoring a library and want to allow this capability, then interfaces are the way to go.

1interface Color {
2    primary100: string
3    primary200: string
4}
5
6interface Color {
7    primary300: string
8}
9
10// let's see how it works in type aliases
11type ColorBase = {
12    primary100: string
13    primary200: string
14}
15
16type ColorExtra = {
17    primary300: string  
18}
19
20type Color = ColorBase & ColorExtra
21
22const color: Color = {
23    primary100: '#fff',
24    primary200: '#ffa',
25    primary300: '#ffb',
26}

For functions from a readability perspective type alias may work out better

1type GetBrandColors = () => string[];
2
3interface GetBrandColors {
4    () => string[];
5}
6
7const getBrandColors: GetBrandColors = () => ['primary', 'secondary']

Whether you’ve chosen a type or interface the way we use it with a class is the same

1type Size = {
2  size: string
3};
4
5interface Milkshake {
6  name: string;
7  price: number;
8  getIngredients(): string[];
9}
10
11class Order implements Size, Milkshake {
12  // Size
13  size = 'large';
14
15  // Milkshake
16  name = 'Vanilla';
17  price = 399;
18  getIngredients() {
19    return ['vanilla', 'ice'];
20  }
21}

Type aliases can represent primitive types, but interfaces can’t. Interfaces are restricted to an object type.

1type Primary100 = string
2
3// literally can't work since the consumer of this type will now have to be of object form.
4
5interface Primary100 {
6    value: string
7}
8
9// the below will throw an error as it's expecting object of the form colorPrimary.value
10const colorprimary100: Primary100 = '#fff'
11
12// let's see anaother example with arrays
13type Colors = string[];
14
15interface Colors {
16  [index: number]: string;
17}

Type aliases can represent tuple types, but interfaces can’t.

1type Point = [number, number];

Type aliases can use computed properties. The in keyword can be used to iterate over all of the items in an union of keys

1type Props = "variant" | "title"
2
3type Button = {
4  [key in Props]: string
5}
6
7interface Button {
8    // errors out as we can only use "primitive types" in computed(dynamic) keys
9  [key in Props]: string
10}
11
12const button: Button = {
13  variant: "primary",
14  title: "Click Me!"
15}

Conclusion

There’s no silver bullet as to always use type alias or always use interface, it depends case by case and depends what do you want to achieve in each case. 🤷🏻‍♂️

If you like this then don’t forget to
🐤 Share
🔔 Subscribe
➡️ Follow me on Twitter

Ughh, type vs interface

Conclusion

Join the Newsletter

More articles from Kamlesh Chandnani

Change what you can change

Service Worker and Server Side Rendering, hmm? 🤔