TypeScript Fundamentals Interfaces
This course has been updated! We now recommend you take the TypeScript Fundamentals, v3 course.
Transcript from the "Interfaces" Lesson
>> Mike North: So some of you may have run into an interesting additional constraint that we deal with when we are working with Typescript and that is, excess property checking.. So when we are working with object literal the type checking is a little more strict than when we pass things into functions for example.
[00:00:21] If we define a variable called myCar and we say that its type is that it has a make, model, and year. And then we try to give that variable a value, right, so the top is just the declaration, the bottom is the assignment. We're gonna get an error saying that the type, and then it will describe the value we just tried to assign, is not compatible with the type that we used when we declared this.
[00:00:50] It's not assignable to that type. So normally you would say, it seems like we've said that excess properties are fine when we pass them into functions. And the reason is that when you have object literals, you can only specify their properties that are known. And this is one of the great strengths when we deal with things like React, where it saves us from things like typos.
[00:01:18] Where even if we have optional properties and we'll look at how those are represented,. We still have to define upfront the set of things that are allowed and expected when we're working with object literals. This helps us make sure that we're creating, when we say this is an object of a particular shape we wanna create something that aligns with that shape.
[00:01:38] We could have fixed this in a couple of ways, one is we haven't learned how to do it yet, but we could have figured out a way to make color an optional property on this type. There's another way though and we could have done it via what's called casting.
[00:01:56] Well, we already talked about casting. Well, we could say I'm gonna initialize myCar with this value as and state the structure that it expects. This would allow it to have that value there. But whatever is like treating it as the above type here that is lacking color, that will not be able to access that color property without getting a complaint from the Typescript compiler, right?
[00:02:25] So if you say, I take an object of the following structure, you're not allowed to reach in there and grab any arbitrary property off of it. Because you're saying, I want a guarantee, give me a compile time guarantee that the object I'm gonna get looks like the following, and you have to operate within those constraints.
[00:02:45] So if we wanted to do something like that and let's say we had multiple cars involved. We could write something like this and you can see it's starting to get really verbose and repetitive and we're bound to make a typo somewhere and if we had to add a property to this shape.
[00:03:05] We'd have to add it in a bunch of places. So this is where something is coming along to address this pain, and it's called interfaces. We can define an interface, which it is simply a shape of an object. Names of properties, types that the values of those properties can have.
[00:03:24] And we can refer to it by name and so the same code will look kinda like this. Where we can say okay, I've got this conceptually I've got a concept of the car. And it's gotta make which is a string, a model which a string, a year which is a number.
[00:03:38] And now we can use Car where we were using that structure before, we can go around and replace it. This is great because now if we wanted to alter Car we've got it one place.
>> Mike North: So interfaces just are, they just have structure, if you are used to Java this is the same as a Java interface.
[00:04:35] And then, that property would be fair game to use across all things that declared themselves to be that type.
>> Speaker 2: What would be the different use cases for an interface versus a class where you'd actually instatiate an object on that class?
>> Mike North: Good question, use case for interface versus a class. So when you define that's a class you're kind of limited in terms of how you can mix and match that behavior.
[00:05:17] So, for example, if I were to say, I wanna describe things that have a length and where I can use bracket notation to access an individual item in that thing. So that describes both a string and an array, right? I can say string bracket zero, or I can say array bracket zero.
[00:05:41] In order for me to be able to say, I'm a function and I wish to take as an argument, something that meets that criteria. If I were to express that in terms of a class, I'd have to kind of go around and insert that as a super class of some of those different types of objects.
[00:06:22] You wanna sort of describe only what you need and that may be a interface that it is not expressly implemented by whatever it is being passed into you. It just is a description of shape, right? When you say, I'm a function and I take this, you don't wanna talk about what is your parent class and give this to me.
[00:06:46] You more wanna say, I expect you to have the following properties and I am going to treat them as having the following values. And when you state that up front now TypeScript will yell at you if you ever break that convention as we all are likely to do, right?
[00:07:02] If you pass the wrong variable in, it'll let you know.