Types vs Interfaces

[00:00:00]
>> Steve Kinney: What is the difference between type and interface? That is an amazing question that we should cover right now. Increasingly little, right? If you had asked me that question several years ago, I would have said there's some overlap, but they're kind of different. If you asked me that 10 years ago, I'd be like, they're very different. Every year that goes by, they are somewhat closer to each other. So let's kind of take a look at that and answer that question.

[00:00:33]
For the most part, other than a few little edge cases, and I can, I'll find a little table later that nobody wants to watch me go look for in my own notes right now, but I'll find it for you of the difference, but generally speaking, there's a lot of overlap, and I would argue, like picking one makes sense, but if we wanted to turn name tag props into an interface instead of a type, you do interface and you get rid of the equal sign.

[00:01:02]
So it kind of looks more like class than like, or like function versus doing constant then equals a function. And we could argue that the amount of differences between doing like the function declaration versus a function assignment where they're kind of mostly the same, except for a few little differences is probably true here as well. Let's say the big difference is when it comes down to extending an interface or a type.

[00:01:30]
And we'll see this later when we do the TypeScript deep dive, but it's worth talking about now. Is, let's say, let's pull this apart a little bit. We're going to have this idea of an interface employee. Or maybe I'll even spell it right, who knows? And that'll have a name and a title. And then we'll say like, we'll call it the name tag props, and we can say that it, gotta get rid of that equal sign.

[00:02:07]
It extends employee. Right, looks a lot like a JavaScript class. And as you can see, everything works is now name tag props are everything an employee and also these two additional fields as well, right? You can do something similar with the type, the syntax is a little bit different, we'll use an intersection. But if you find yourself like, hey, I just want to take an existing type or interface and extend it, and what's kind of cool is I could make this a type.

[00:02:36]
And you can see that it still works, right? The thing that is doing the extending needs to be an interface, but you can extend a type, you can extend an interface, TypeScript doesn't care. If you want to do something similar to this with an interface, you would need to do an intersection. So we would say type name stack props equals employee and this type. The nuance between the two really comes down to when you want to like override stuff, right?

[00:03:22]
And so, if, you know, for instance, let's say level was a number here. And all of a sudden we wanted to make it a string, right? We could feel like you'll get the error over there. We can kind of do that a little bit with the intersection, I believe. The problem is this world keeps changing, we'll find out together. I believe it's going to be like, hey, yeah, if I try to kind of make a different type at this point when extending the interface, it's like, hey, it's a number here and now you're making it a string.

[00:03:55]
So you kind of do have to like, extend, like it says on the 10, effectively extend it. So there are some little nuances and stuff along those lines, and there's places where like, hey, the very simple. The thing I want to do with a type is hard and you do with an interface, it's easy. I tend to like to use type. I'm not going to tell you that's because X, Y, and Z reason. I think the consistency across the codebase is more important than any given one.

[00:04:17]
So like, whatever you're doing in your codebase is fine. You're like, I saw this workshop and Steve said we had to change all of our interfaces to types. He'd never said that. Mark, what he says, types don't merge like interfaces. Yeah, you have to like kind of omit things and we'll kind of see that a little bit later. If you wanted to like totally change something and it wasn't compatible, you can like, hey, I want every type but this other one.

[00:04:42]
The, you know, it's kind of like one of those things which is like as we start to do trickier things, like one becomes easier than the other, but generally speaking, the over like the circles of the Venn diagram are eclipsing rapidly. Cool, cool, cool, so let's turn that back to a number. And you'll notice that when I said now level as a string, this file over here turned red and angry because it's giving it a number.

[00:05:09]
And that's the nice part of using TypeScript in a larger codebase is you made one innocent change, right, and you got alerted to all the places where that might be problematic, even if it's not truly problematic, right, because like in this case, that's going to get rendered as a string regardless, right? But in lots of other cases, to know that that one well-meaning change. Is, you know, maybe, because in a large enough codebase, the biggest problems are like, I was working as one piece of codebase and that had some weird effect, like 17 files over, right?

[00:05:42]
Having something that will instantaneously give you visual feedback, both even in the file as well as across the codebase, and then obviously we can run like a type check and we can have CI/CD and all those fun things there as well, are super useful. So let's turn that back to a number though. Cool. And so that's effectively, even this is like we made it. A little bit more complicated, right? We could get as far as.

[00:06:16]
This component with only this is now completely type safe. Right? If we tried to put in true or if we left off level, right? If we went back to this component over here and we took off this property. Right, we are instantly told that we have made a boo boo, right? And normally that would turn into a whole bunch of either end-to-end tests to make sure you didn't break something over the other part of the application, or a bunch of unit tests to see, well, what happens if undefined goes in there, so on and so forth.

[00:06:46]
Now, there's a time and a place for those tests what we'll get to when like stuff coming from the outside world might not be what you. Said it was and stuff coming from the outside world by default will a lot of times be any, like local storage or fetch requests or stuff along those lines. We will come up with a strategy to solve for that as well. But you know, in those cases, if one was extra paranoid, one could then also decide that they wanted to have some unit tests for that as well.

[00:07:20]
I only say that because I've done it, because I'm extra paranoid. Awesome. Cool, cool, cool. So that's kind of the theme which is ideally as little, as much TypeScript as we need, and as little as we can get away with.