TypeScript interfaces and generics are one of the best ways to drive consistency and provide better reuse of code across your code base.
Join Pluralsight author Dan Wahlin for a webinar on these tools and walk away knowing:
• The different TypeScript types • How to create and use interfaces and generics • When to use types versus interfaces And more! Don’t forget to stay tuned after the presentation for an audience Q&A with Dan as well.
Visit us at: Facebook: https://www.facebook.com/pluralsight Twitter: https://twitter.com/pluralsight LinkedIn: https://www.linkedin.com/company/pluralsight Instagram: http://instagram.com/pluralsight Blog: https://www.pluralsight.com/blog
And I'm excited to be there we go now. It says we're recording, so welcome, everyone. I'm excited to be here with you today. My name is Dan Wallen. I'm a plural site author, and my full time job is I'm a cloud developer advocate at Microsoft, and I'm a big fan of TypeScript. Been working with it since it very first came out, and it's one of my actually favorite languages. I have some other favorites, probably like you, but we're going to talk today about not only TypeScript, but specifically interfaces and generics and how you can use those in TypeScript. So I've already introduced myself. You can go to blog code with Dan. Com if you're interested, or if you're on Twitter, feel free to get in touch. In fact, afterwards, if we get a lot of questions, I'm not able to get to those feel free to run off to Twitter and you can ask me there if you'd like. Speaking of questions, if you do have any, go ahead and put those in the Q amp. A. I did a session for this. What was it a couple of weeks ago and we had a lot of questions. So if you have any, I'll stick around after and be happy to go through questions with you as well. So feel free to do that. But please use the Q amp. A. All right. So the agenda today is the following. I'm going to start off with just a real quick review of Water TypeScript types. Now, type script has the name type script for a reason, of course, and it's because of the type. So we're going to talk about those just real quick. If you have done any TypeScript before, you'll have already seen this, but it's going to tie in nicely to interfaces. And I'll kind of talk about how that ties in. Then we're going to go in and kind of talk about the case for interfaces. What is an interface? Why would you use it? But I'm going to introduce that topic by first sort of walking you through some scenarios where you might go. Oh, yeah. That'd be pretty hard to do with just plain JavaScript. So we're going to talk about how interfaces can help us out. And also I'll sum it up by saying they can help us out. A ton. Interfaces are if I had to rank my top five features of TypeScript, interfaces are probably in the top two of my favorite features, so they're pretty nice. Then I'm going to walk you through the process of creating and using an interface. I'm going to be using something called the TypeScript Playground for most of this. And that way you can follow along if you'd like. So if you want, I'll give you a URL. You can go to that and you can kind of play with it as well as I do it from there. We're going to clarify something that when I first got started with TypeScript was very, very confusing to me. And that is, TypeScript has something called a type keyword, but also has an interface keyword, and in some cases they can do similar things. In some cases they can't. So we're going to talk about what is the difference between type and interface. So that when you do see that in your top script code, or maybe a code base that your team is working on, you'll hopefully have a good understanding of what is that? What does it do? And then finally, we're going to wrap up with a quick look at generics. Generics are code templates if you haven't done it before. Very powerful, though, and used a lot as you work with if you're doing, like React or Angular or even other libraries and frameworks. Generics are a big part of that as well. All right. So let's start off by discussing just really quick, what are TypeScript types? So we know TypeScript is called type script because it has built in types, of course. And we have these kind of big four types number, boolean, string and array. But then, of course, there's others. You have any because variables, parameters, they can be anything, meaning that they can be assigned a number, they can be assigned a boolean string. Whatever. I'll talk about that, you might have a function that returns nothing. It just performs an action, but does nothing that's void variables can be undefined. They can even be unknown. We're not going to go into that today, but there's unknown. There's never. You can create couples and enums, and the list goes on and on and on. You can do all kinds of really nice stuff. So when you start out with TypeScript, you probably learned that you can have a variable, you can put a colon and you can give it a data type. But normally when we do that, we're using the primitive data types, like Age is maybe a number, or we have a name that's a string is loaded is a true or false a boolean. We have arrays. Arrays are very common, of course, because we have collections of items. And these are the main four that you'll typically use. But a lot of us, we're not working with just number strings, arrays and booleans. We have more complex data structures, and we need to be able to use those as well. And type of variable as, for instance, a customer or an invoice or purchase order or whatever it may be you're working on. So the case for interfaces is the following. First off, what is an interface? Well, an interface is a code contract. And the first time I heard that I went, okay, that doesn't help me much. So I'm going to clarify that for you. But if you are doing a job interview or talking to somebody and they ask you, what is an interface? You could say it's a code contract, which again, doesn't mean a lot unless you know what that means. But we'll clarify that. Alright. So before I show you interfaces and we're going to do a lot of just live coding here in just a moment. What is one of the cases where you would use this? Because for me, before I learn any technology, I always like to know, why would I use it? I mean, yeah, it's great. I can brag. Hey, I know interfaces, but why does it matter? What problems is it going to solve? Let's talk about that. So let's say that you have a banking account object and it has a withdrawal and deposit function. You have a brokerage account object, same thing withdrawal deposit and you have a gold account. Now let's say that I'm working on banking account. We're all on a team. Ruth is working on brokerage account. Jim is working a gold account. How do we drive consistency across our objects? How do we make it so that we all have two functions called withdrawal and deposit? Well, we could have a team meeting and just say, hey, Jim and Ruth, whenever you write this code, make sure you put withdrawal and deposit. But even then, there's no guarantee that I don't say, well, I don't really like the name deposit. I'm going to call it something else. Right? So what we could do is we could make an interface. That is a contract. I could hand it out to myself, Ruth and Jim. And now they will use this interface. And if they don't put withdrawal and deposit, then guess what happens. Typescript gives an error when it builds. And I'll show you an example. This coming up. Now, when you name interfaces, some people like to put an eye in front of them because that kind of differentiates them from classes. However, some people hate that. I like it. I kind of came from a C sharp dot net background. I did Java before that. Java folks typically don't like that. If you're just JavaScript, you need to make a choice. Here's the answer to what's the right way to name an interface which is coming up. Actually, the answer is make sure it's consistent. As long as you name it consistently across your team. It really doesn't matter. I do like putting an eye, but I've been on teams that I've run where people didn't like that. So we didn't do it. We just had a team basically design guideline that said how we're going to name all our interfaces. So in this case it's a account and I'm going to show you how this works. But what this will do is now I have to have withdrawing deposit because it's kind of like signing a contract. And that contract says, hey, Dan, if you sign this contract, you must have withdrawal and deposit in your object. If you don't type scripts going to yell at you, type script is going to give an error. Now. Likewise, brokerage account. Let's say this is Ruth. Alright, brokerage account also has to have that. So Ruth signs the contract. Of course we do that in code. And then Jim has Gold account and Jim signs the contract by using the interface. Alright, so that's kind of one scenario is we can use interfaces to drive consistency across the set of objects, which is actually very powerful, especially as you have a larger project and a lot of team members. Now here's another example. If we have this little get property called account info. And if we have a routing number and bank number that's returned when I come down here and I create a new banking account and then I say account account info. So we call into this property and we get this. What is the data type of info here? Like, what are you getting back now? Today's modern Editors might try to help you out and you might see that you have a routing number and a bank number. But even if it shows you that what's the data type is it supposed to be a number? Is it an Alpha numeric string? What is it? Well, with JavaScript, there really is no way to know that because JavaScript it can be anything, right? Because JavaScript variables, you can assign any type of variable. So what can we do to help with this? Well, let's take a look. What if I did this? What if I said that this property returns an I account info. Now what is y account info? Let's say it was defined this way. Let's say routing number was defined as a number. A bank number was defined as a string. Well, now when you call into this property as you're typing your code, you're going to know what you're going to get back. Exactly. Not only you're going to know that it's going to be an object that has routing number and bank number, but you're also going to know the data types of those so that you can work with those, convert them, whatever it may be. So it'd be kind of like me doing this. When we call account account info, it calls into here TypeScript goes, oh, this returns an I account info or account info. If you don't like the I and then notice here that it then says the shape of that data. So again, it's kind of like a contract that says if you call this property, I promise to give you back an object that has routing number and bank number, and I will give you the data types. Now, this variable we now know is an account info an interface. Now you don't actually have to type this code right here. And the reason is TypeScript has something called type inference. And if you've been using TypeScript much, you probably know this. But if you haven't type inference is where when you call a function or you call a property or you assign like a string to a variable. Then it just automatically looks at what's being returned from the function or what's being assigned and it figures out the data type. So in this case, this code right here is redundant. I don't really need it. And the reason for that is because it will see this and go, oh, I know what it is. And so I could just say let info equals account account info. And again, I'll run some examples here once we get through the scenarios. Right. So that's another scenario. Now the final one is something I run into a lot you're working with, maybe a third party. We'll just call it plug in back in the day. I used to do a lot of Jquery long time ago, the good old days, right? And you used to have these little plugins you could use for calendars, data, grids, autocompletes things like that. And you'd have to initialize the plugins with some settings. What size do you want? Maybe you override colors, stuff like that. If I were to give you this scenario here and say, okay, go ahead and use my object plug in. What would you pass in for Settings? I think most of us are going to go. I have no idea. I'd have to go look at the docks or I'd have to go look at the source code of this and I have to figure out what are the properties of the Settings object? It's kind of hard to know at this point. Right? So what if we did this though? What if we said Settings is of type I settings? And again, I for interface. And what if Settings had a title and a position and maybe title is a string positions? Probably a string or it could be a point. Maybe an X and Y point. Now would be very clear how we could use this object because the interface would define that you're supposed to pass a title and a position into this. Okay, so that kind of sets the stage. Now I have a bunch of slides. I'll give you a link to the slides by the way, at the end. But death by slide is a hard way to die. I don't want anyone dying from death by slide. So instead what I'm going to do is and I'm zoomed in so you won't see Playground. I don't know. Actually, there we go. You'll see it there. But if I Zoom in one more time, it will go away. But if you go to TypeScript. Lang. Org. Alright. Text script, Lang. Org. Then you're going to be able to click on Playground. Now I'm going to Zoom in just a little bit more in Playground, not super responsive. It goes away. But this is the official TypeScript website. You'll notice that you can learn about how to get started with TypeScript. You can go to the docks. They have a book about it, a handbook, community information tools. And then Playground is also there when you're not so zoomed in like I am. Now what I'm going to do is let's create just a function called my plugin that takes settings and then we'll just put a comment that says plugin does something here. Now you'll notice first off, I'm in TypeScript. In fact, I'm on the latest version of Tax script. Four, three, five. Notice how Settings is red light. Settings is declared, but its value is never used. And Settings implicitly has in any type. Now let's go ahead and we will just log so that we can use it. Well, log settings like that, but still it's red. Now first off, let's clarify some of you probably got this air before parameter saying implicitly has any type. Well, TypeScript is saying I don't like this because you are implicitly saying this could be anything. It could be a string, it could be an array. It could be anything. The reason for that is we come up to the TS config. If we come on down here just a little bit, you'll notice I have some strict like no implicit any. Now if I turn that off, I can fix this. But you don't want to turn that off. This is a good thing to have. Now I could fix it by cheating and we could do that. Alright. But now when I call this function, look what it says. I'm supposed to pass. So now again I'll ask you what is settings and you're going to respond with it. Anything. Dan it says it. Okay, fine. What are you supposed to pass though? Let's say it's an object. What are you supposed to pass as the properties here of the object and we don't know. Okay, so let's fix this with an interface. So I'm going to come on up and we're going to do an interface and I'm going to add an I just so you know, it's an interface, even though everything is right here. Let's call it Ice Settings. And let's do what you saw in the slides. Let's add a title and let's say that's a string. And then let's add a position. And for now to keep it simple, let's just say that's also a strength. Okay. Now I'm going to change this any to an I settings. Okay. So now when we mouse over it, notice that it says Settings is an I settings. But what's so powerful about this is now when I do my plug in. Well, actually, let me back up there. And let's put this again. Notice it says Eye settings. Now you may say, well, that still doesn't help me much. Well, it kind of does, because if you're in an actual code editor, you can now right click on these things and say Go to definition and go to definition will then show you here's the interface. Here's the contract here's all the properties or functions or whatever it may be that you may need. And Andy, excellent question I will address that coming up. Excellent question. So let me come back to that. Now let me go ahead and first off, show you though, that if I try to call this function and I pass an object, notice it's red. Why I didn't follow the contract. What's the contract say? I must have a title and a position. Okay, so let's put a title. But let's put a number for the title. Let's put a position and we'll just say we'll just put something like that. Something simple. Alright, now position looks good. But notice title is not. And again, if you've done any type script before, you're probably used to this, this one's pretty simple type number is not assignable to type strength. Okay, so we can fix that title and we can just put my title. And there we go. So now as my team is working with this, it's very clear that you must pass some type of object that has a title and a position. And if you don't like if I take this out, watch what happens, see how it goes red. So I like to say this adds guardrails. If you're ever driving down a road that's really curvy has a lot of clips on it. I live in Arizona, in the United States and Arizona is famous for the Grand Canyon, but we have a lot of other canyons. So when you're driving, there's a lot of cliffs in spots, so we have guardrails. Well, that's what this is doing. This is adding the guardrails and saying, hey Dan, you're about to crash off the road of TypeScript. Please fix yourself, adjust yourself. And then of course I'd have to add title. Now, that would be one example of an interface. I've now defined a custom data type. Now let me go to Andy's question, why not use a class instead of an interface? And let me answer that by showing you something. So in the TypeScript playground and there's this little arrow, I hit this, but normally this will be showing this is the JavaScript that gets generated. Now do you see anything missing? There the interface. What I like to joke about interfaces are interfaces taste great. Zero calories tastes great. Zero calories. That sounds like some soft drink out there, but interfaces are development time only they will add no size to your JavaScript that ultimately is going to ship and run in the browser. Okay, so that's why I say taste great. Zero calories. They taste great, because if I mess something up during development, it's going to tell me so that tastes great. But at runtime runtime in zero calories, there is no impact at all on the runtime performance size of my JavaScript files. And normally we're bundling with web pack or Parcel or something like that. In this case it's just raw output, but no interface now. And that still doesn't answer your question. So let me answer by doing this. We'll just call it. Well, we'll leave it. As I said, it's just not mess up things. Now, in this case I just need to assign because it could be a runtime object. So notice there's two answers to this question. Number one is if you need to instantiate and that's bugging me. So let's just fix it. There we go. If you need to instantiate settings, new it up. In other words, then you're going to need a class because interfaces never see the light of day. They never make it into the browser. Classes do, of course, because classes could be used as a runtime. So for example, I could do this or I could do this. And then I could say my settings dot, give the position and my settings dots and give the title. And then I could pass my settings. So if I need to be able to create the object instance, then a class works great. If you're using classes, you could also use functions by the way, to do something like this. So if you're anti class because there is a crowd that is anti class out there, you could do that. But what's the difference then? So to answer the question, Andy, number one classes make it into the JavaScript that goes to the browser. So it is going to add to the size of your bundles if you need to now it up. That's no big deal because you need it. But if you're just using it for the data type and that's all, you're not going to new it up instead you're going to do let me go back to what I had here instead, you're going to do this like that. Well, I don't need to new it up because I could just pass the object literal right here. So I hope that helps to sum it up again. If you need to new up or instantiate an object and you do use classes in your code base, then classes weren't great because they can also be used as data types. But if you only need the data type, the shape of the data for development purposes only go with an interface. Why bloat your code if you don't ever use that object in your code makes no sense. Right? You might as well just do what I did. So. So. Excellent question. Alright, so moving on. Let's talk about some other scenarios here. Now this would be one where we pass into settings, but let's say that my plug in passes in. I don't know, passes back. I should say a plug in object. Well, if this is an object that is just an object literal again, and I don't want to bloat the size of my JavaScript code. And when I say bloat, it's not like it adds that much to the JavaScript, but it does add a whereas the interface adds nothing. So I'm going to give you two options here. I could do I plug in and let's just say this has maybe the name of the plug in, and maybe there's an init function or something like that that returns void. So it has two things that returns me turns an object that has a name of a plug in and it has at a net. Now here notice it's red because I never returned anything. All I did was a console that log on the settings. So now we can return an object. But now the guard rails go up and I have to put in the name. Let me name it something else because name is window name. So let's call this plugin name just so it doesn't get confused. I plug in and then we can put a function it that does something. I'll just comment out console log started. Now, that would be one way to handle this. Now I know the shape of the data coming back. So when I call my plug in and if I say let's you know my dash plug in, let's say equals if I mouse over this actually doesn't like that. So let's just do that. There we go. Notice the data type there. I plug in. Now. I could right click on that. If I'm an editor and I could drill into it and find out that, oh, I'm going to get back a string and I'm going to get back in a net function. And now I could say plug in. And there it is. Look at that. Intel uses that code help I get. Whereas if this was an any, let's go ahead and make this in any really quick. Wow, that's awesome. I get nothing because the editor doesn't really know what's going to happen until runtime. Okay, so this is where TypeScript really shines, because now at development time, go ahead and change this back to an I plug in. Now, when I do plug in dots, boom, I get the code help. I get the guard rails. I get all this extra benefit and look at that zero impact on performance because it's not a class. It's an interface runtime only. So we could probably net or something like that. Okay. Now if I needed the plugin as an object instance that I need to instantiate myself, and again, we can always make this class, I probably wouldn't call it I plug in. I probably call it plug in, and then I have to fix this. But we could do that. Just keep in mind it's going to influence the size of your bundle. Okay, so if there's any questions on that, feel free to add them into the Q amp a there. And I'll be happy to go into that a little more. Now I want to go into a little more simple example. Let's say that you're creating a customer and this customer has first name and last name like this. Now, that's great. But what's the data type of customer? Well, it's an object. Okay. It's basically kind of like doing object right here or we could even put any. But if I do customer dot again, I get no code help there. And if I'm going to pass this around in the app, wouldn't it be nice if not only we get the guard rails to help us if we forget something, but also to help us with code help. So let me go ahead and let's do the same thing you just saw we could do an interface or class again. It really depends on what you want to do. I'll even show you we can do a type a little bit later, but we have an interface here and let's call it. I'll just call a customer for those that don't like the eye, you don't have to put the eye and we have first name, string, last name, string. And there we go. There's another interface. Now, if I Mark this as a customer, this changes everything. First off, if I forget that this goes red and it says, hey, you're missing first name. Okay, I broke the contract so it's kind of like the bank is going to come after me and repossess my car or something. It's the TypeScript compiler. Fortunately, so that's a benefit that's the guard rails. And then also when I hit do look at that first name last name. Beautiful. Alright, so that'd be another one when you're defining variables. Oftentimes it's nice to know when you're working with the right shape of data. How many of you call in to a restful service at work? And I'll bet you the answer is a lot of you a service that you pass. It something that gives you back a JSON object. Well, a lot of times it looks like this. Let's my data equal. I'll just call it get data. It'll probably be async. So we'll say get data. Maybe I pass in an ID or something. Normally you do this and then my date is just in anything. Well, what if the data that the service return? What if you mean an interface? And what if it was a customer that's returned? Now this is going to stay red because obviously I don't have a get. Actually, that's supposed to be data. Well, by putting this now that data you get back from the server, it would actually be available to you to use to get IntelliSense and do all kinds of cool things. I'll give you a real quick example. There's a really cool restful API kind of testing side out there. If you're a Star Wars fan, you'll like this swapped Dev and you'll notice you can get back Luke Skywalker or I can get a bunch of characters. Go ahead and request that here's. 82, although they page the characters. So we get Luke and I think C three, PO and Darth Vader and R 2D two and all the characters. So this would be like calling a restful service. Well, a lot of times what I'll do is once I know the shape of the data, I'll use a tool to convert this to an interface and I'll show you one of these. So I'm just going to copy that JSON and then there's some vs code plugins for this. If you use vs code or you can go to JSON two to the number two TS dot com. I can paste in the JSON and look at that. It actually will make an interface. You'll have to rename it. And there's other websites that will do this too, by the way. But JSON two TS dot com and now I can come in here. Let's call this customer. I'll take out the export for now. Alright, and there we go. So now my customer has all these properties. Notice it's red. There is no first name. Now I'd have to go in and fill out name, height, mass, hair color, all these things. Okay. And that would be another example. Now let me real quick. Switch to questions here. Can you define functions inside the interface? No. So that is an excellent thing to talk about. Anonymous attendee. I don't know your name. Let's just say we had a if interface when I did a knit earlier like this and I said it was void or maybe returns a number. Who knows? No. An interface never ever has real code. An interface is just defining the shape of data. That's all. I think of it as it's like defining the API, but it doesn't define how to use the API. Alright, whoever implements the interface, they would have to do that. Now let me real quick. We're going to cover this anyway. So let me keep going on this question because it's a good question. Let's say I had a class called Food that implements if this is how you implement an interface. If you're using classes, now notice this class is now red. Go ahead and read that error real quick. It says property. It is missing. So with an interface you will define the function if that's what you need in your interface. Whoever implements the interface is then going to be in charge of implementing the init function in this case. So now I'd have to come in and say a net and then we can just add a quick initialized or something like that. So that would be an example. Now look at the code on the right though. See that there's no interface. That all drops off because the interfaces are TypeScript only they help us as developers, they have zero impact on performance. So hopefully that helps out with that question. Good question. Okay, let me come back to that one because that one I can't really tie into this demo. Excellent question. Let me see if I remands. I don't know if I said your name, right. Cool name. I haven't heard that one, by the way. Remind us. I don't know if I'm doing that right, but let me answer yours because that ties into this. Remember how right in here? I said we have a problem now because now my customer has 123-45, 67, 89, 10, 11, 12 about 1617 properties. I have to type all of those. So if I want to make any of these members optional, as was just asked, I can do that. What you can do now let's say name is not optional. Alright, so let's put name. Our customer is Luke Skywalker. Alright. Height. Well let's say that's optional because I don't know. Maybe certain species you don't measure by hide it by width or something. Who knows? Maybe they're super low to the ground. I can put a question Mark. So for anything that I want to be optional in an interface and this is a powerful feature. Now notice how this is red right now. I'm going to make all the rest of these optional real quick. In fact, we don't really need all these. Let me just clean this up. There we go. Now notice the red went away. I satisfied the contract. Okay, I said that you must have name, but you don't have to have height. Now, if I want to add height, let's say Luke is. I have no idea. I'll just say 6ft. Oh wow, I'm in us. That's just wrong, right? We'd have to do metric. Well anyway, 6 meters would be a bit out there, but hey, we'll pretend looks, you know, big guy, that would be an example of that. Now if I want to make it where it's not optional. Of course I just take that off. Now, if I don't put height, this goes red and it tells me this is the guard rails. Hey Dan, you're driving off the road. You're not doing this right. And so now beyond me to fix it. Pretty cool. Alright, so hopefully that helps. Let me close this and this. Okay, what are the practical differs between the interface and a type? Oh, we're going to cover that. I have an actual slide just on that topic. Excellent question. Because I mentioned at the start of this that was one that really confused me. And I won't ask for a show of hands because nobody wants to admit when you're confused. But you know, in your head how many of you have been confused by that? You've done TypeScript. You've seen interfaces and you've seen this thing called type. We're going to get to that. So give me a little bit. We'll swing back. Okay, so that is a quick example of kind of getting started with interfaces. Now to review that, I'm just going to go through something really quickly here with you and then we'll get to the type and interface question. So here's an example of a really simple interface called I message. It has a green property. It's a string type. Okay, that's very analogous to what I just did. Right? No surprises. Now, here's another interface that has a function called greet. It takes a parameter, a message of type I message. So the parameter is an object that has a greeting property. That's a string. Notice that this green function returns void. So there we go. We've now defined two interfaces. One is going to be used for the parameter. It looks like the other I greet is going to be used to define a great function. We now know the parameter data type, and we know it doesn't return anything. It's void. How could we use these? Well, here's one example. In this case, we did a class that implements I greet. Well, what does I greet have I greet had a great function. There it is. There's the exact signature that you just saw. So if we break this down there's the I greet. It had to have that. If you forgot to put the greet function, what would happen? You would get a bill there. Okay, now we know message is a type I message. Well, I message over here had a greeting property in it. So now we know that we can call message greeting because we know this was an object of type I message. Now again, what is I message? Well, in Webstorm Visual Studio vs. Code, more robust Editors like that, you could just right click on it and say, go to definition, and then that would show you the interface and you say, oh, it has a greeting, or you could just use the intel sense like I showed earlier. You could type MSG dot, and then you would see whatever that interface has inside of it. Super powerful, super productive. So you get the guard rails, you get the intel sense, you get improved productivity. It's like you can't really lose, especially on larger apps where you have a lot of data types floating around. Now, here's another example. This is an interface that actually is based on another interface. This is another thing you can do, and it also shows these optional properties. Now, when you extend, this is a keyword that is not type script. This is actually a keyword that comes from E 2015 JavaScript. This is normally what you use to have a class inherit from another class in JavaScript. That's the typical way you do it. In this case, that's not what we're doing. My account is extending I deposit withdrawal. So I account has four members. If I deposit withdrawal had four members, that would be eight. Obviously, if my math is correct. Very hard math calculation, of course, but we can subtract one off. Why? If this has four and this has four, then if I give this account to you, how much do you have to do work less? Well, normally the answer would be eight things, but we could subtract off one because this is optional right now. What is the correct way as you're defining these, then to name these. And I'm going to show you a demo of this real quick. What is the correct way to name these before I show the demo and the answer is there is no correct way you name with consistency. Okay, so if you like the I use the eye, but be consistent if you don't, don't use it, but be consistent. Now let me go back to here really quick. Before we get to the types section, let me show you what I mean by this. I'm going to clear all this out. We're going to paste this in, and I'm going to add a new interface called I deposit withdrawal. And let's just say it has a withdrawal, not with and it has a deposit. I don't know if I spelled that close enough. Okay. And then there's even an I account info. Okay, so it looks like we need that I account info. And let's say that has an account type, which is a string or something like that. Okay, so now we have three interfaces. If I implement my account, what work would I have to do? Okay, so in other words, if I did this, what do I have to do? Well, right off the bat, it says you are missing account info, balance, title withdrawal and deposit here's. The guardrails just came up. I instantly know what I'm supposed to do. How cool is that? I think it's pretty cool. So we'd have to say a town info, and it's an object that looks like that has what is account info have in it an account type. Let's say this is a checking account. What else do we need? We need a balance. We need a title. Am I done? I could leave this out. It's optional. What am I missing? Let's mouse over withdrawal and deposit. I also have to have those functions. Now I'm just going to fake those. Do some real simple ones. Okay, so the reason I want to point this out is if you're an architect or a team lead or just kind of the person people on team look to for guidance and you're designing the data types of your app. Now, this could be a node JS app. It could be angular, could be react, it could be spelt. It could be anything. Type script runs anything that's JavaScript. Obviously, you can now break down your interfaces into little bitty puzzle pieces, and then you can start to put those puzzle pieces together to build bigger interfaces. That's what I'm doing right there. Okay, so now anybody that uses my account, they must also satisfy this. So it's not just these three things they need. They need five things in this case. And that's exactly what I've done right here. Okay, let's see here. We're going to get to that one. Yes, you can. Excellent question to I'm probably not saying your name, right. So sorry, but excellent question. Yeah, you can. So the question was, can a class implement multiple interfaces? Yes, it can. I'll just make a class that implements I account and let's just pretend it also you just put a comma implements I account info for some reason because that's what I have to work with. Well, now I'd have to satisfy both of these. I have to put all this stuff. Plus I'd have to put that as a property. So the more commas you put, the more you actually have, the more code you have to write, the more implementation we call you have to do so. Excellent question there as answer live. Okay, alright, so we're getting close to time here because I want to leave questions at the end, but that's good. You've been asking questions during. Excellent. So let's move onward and upward here. We already did that one. Alright, let's go to here and then we will do a quick review and then we'll talk about types. So would you use an interface or class if you need to create object instances? We kind of already answered this because there was a good question. Would you use an interface or class if you need object instances at runtime and the answer is a class because do interfaces ever make it to the browser? No, we've already shown that. Let's go back real quick and I have a bunch of interfaces here. Look at the code that was generated, that's it all the interfaces are stripped out. Taste great because you get guardrails, you get help, you get IntelliSense, you're more productive, but there's zero impact. And again, if I needed to create an instance of one of these, then I wouldn't use an interface because you can't instantiate an interface. You have to have a function or a class to do that. Alright, so we already answered that. Use a class in that scenario or a function or whatever. You prefer that you can instantiate functions work fine for that as well. Okay, so a quick review of the features here. Interfaces or code contracts. They define the shape of the data and they can help you drive consistency across your code base because if somebody forgets to put a property, it goes red and it won't. Compile classes can implement one or more interfaces as we just talked about their excellent question and tastes great. Zero calories, zero impact on runtime performance because these are development a compile time only. That's the only time you're going to see interfaces. Alright, so let's get to I don't know if I'm going to say no. It was anonymous attendee. Actually I can say that one. The question was what are the practical differences between an interface and a type? Which is an excellent question. Let me show you. So an interface always works with object like data structures. Okay, if we have an account and it has an account number and a balance, then you'll notice that we have the data types then just like I showed earlier, you would have to create an object with those two properties. Okay, so interfaces are always about objects. Now here's another example. We have a nice savings account that extends an account. Extend this one. So there'd be three things you'd have to implement. You'd have to have an interest rate, you have to have an account number and you have to have a balance because this one extends this one. That would also have to be an object could be an object literal, or it could be just a class that implements it, but you would have to have interest rate, account number and balance in there for it to compile. Now let's look at types here. Types can define primitive types and they can define what looks like interfaces. Now let me take this example real quick to clarify this and I'll show you what I mean. Let's go back to the playground. Let's wipe these out and we'll put this type here. Now I can have a variable in this case. Let's call it bank account of type. Account equals. And I could do this string. That's totally fine because that's the first part of the type. This pipe here if you're not familiar with that is an or for data types, it's a Union type. It's called or. In fact, we can even make a different one. Let's do savings account. Now I can do this one. I could do that with a type. You could actually define primitive data types or and or you can define these. Now you don't have to. Of course. I mean, I could just do that. That would be super overkill. Like why would you make a type called account? It's just a string. You might as well just put let's go back to here. You might as well just put strength, but we could say that account could be a string. Or maybe it could be a number. Possibly. Maybe it could be a string version of it or it could be a numeric version of it. And now I would have some custom data types so I can use primitive data types with type. But I can also do this. I can do complex data types like you see here you can't do this part with an interface. In fact, there's my guard rails. Notice I said it's a number. I made a string. So we need to fix that. There we go. What's wrong here? Oh, that's account not account number. Let me do account number. There we go. Okay, so let's go back now. And hopefully that clarifies a little bit if you're just working with objects, which mostly I am to be honest. And you just wanted to find the shape of the object data like we've been doing this whole presentation. Then interfaces are great for that. If however, sometimes you need primitive types or maybe you need complex types, then you could use a type. It either way would work in that case. Okay, so hopefully that helps out a little bit there. Alright. And on the questions. I'm going to finish up. We have one more little thing on generics, which is quick. I'm going to finish that up and then I'll stay after to answer questions. So we make sure we don't go too far over here. Okay. So if you ever see type, just know that if they did it and you look at it and you go, gosh, I couldn't have done the interface for that. Well, like this part down here at the bottom. Yeah. Instead of using type, I could have just made this an interface, but in this case I couldn't have because I said it could be a string or it could be a complex type. Therefore, you have to use the type keyword in that particular example. Jamie, that's a good question. I've Typed us both. Why wouldn't you just use it all the time? And I think the answer is you could first off, a lot of people, though, have a background with interfaces and interface just feel more natural. If I'm only working with objects, then I just prefer to use interfaces, but that's just personal preference. If you prefer to use type for that, go for it. That would be totally viable. That's a good comment there. Yeah. Either way would work. In that case, you do get a little bit more flexibility with the type keyword. Alright. Now actually, this one is bonus. I'm going to skip over that one and we're going to go to this is just another way you could use types right here. I'll let you. We already kind of demoed that. So let's wrap up by talking a little bit about interfaces. Now we're going to kind of change gears here. We were down the interface road and now we're going to switch tracks. I guess you could say if you're on a train and talk about interfaces. So first off, what is a generic? And the answer is it is a code template. Now again, when I said, what is an interface? If you renew to interfaces, I said it's a code contract. That probably didn't help, but I hope now you get the idea a lot better. We're going to do the same thing just real quick here with generics. This one's going to be a lot shorter, though. It's a little quick section, but it's a code template. Now this is something that like interfaces. Many other languages have C plus plus back in the day when I used to do that, it has generics equivalent of generics. It has interfaces. For example, Java has the equivalent of this. C sharp has the equivalent of this, but we're here for text free. So as an example, you get the final rays like this array of substitute the word of when you see this less than array of strength, and this would be totally valid. So if we go back over to here, we could say let pets of type and I could say array of string or I could do let dogs string array. Either of these would work. But this is a generic. It's basically a placeholder where type ship is saying you tell me what data type this array is. That's what that means. So if I say array of number, then when I do pets, ad or push sorry, wrong language. Then I can only add numbers. In fact, notice up top here it says number. Whereas if I said this was a string, if I do pet push notice it now says you can pass me a string so we can pass in side. You get the idea. Now I'd have to initialize this. Something like that. Maybe. Whereas this one down here let's initialize this. Let's make this a array of number. Now when I use dogs push notice it says I have to pass a number. If I try to pass a string it goes red. I don't know why you have dogs and just the number. Maybe you numerically number all your dogs or cats. I don't know, but this is something you're going to see in TypeScript. Now. I want to point out again, just like interfaces. Zero impact on runtime notice. See that no interface code at all. It strips out everything. Type related, interface related, generics related. All that stuff gets stripped out by TypeScript. It's only for us as developers, but that's really the value of the type share language. Is that us. As developers, we as developers are now getting the guardrails, the productivity, the code help all that stuff we've talked about. Okay, so that's a real simple example of a generic. Let me wrap this up by showing you just a little bit more and then I'll show you some code demos you can get to if you want to practice. Now here's another example. Let's say I have a list of numbers object like you see here a class. Notice it has a property called items, which is a number array. You can add an item, you can get the items number, number number. So it's all about numbers. But later on I realized you know what? I need a list of string objects as well. Notice it can only add strings. What's the difference between these two classes? In reality, the data types that's it. The code is identical. It's just the data types that are different. So wouldn't it be nice if we could just make one list of something class and then we can tell it this time. Use number this time use customer. This time you strength that way you have one class to rule them all if you're a Lord of the Rings fan. Alright, so here be an example. This is a custom generic class. Now remember earlier I said in the Q and a thing, what is a generic? It's a code template. This is a template. This code on its own is useless because what is T? What is teeth? T stands for type I don't know what it is, but if I do this and I create a new list of string, what type script will do is assume that this is a string array. This is a string parameter and this returns a string array right here. Now I can reuse this class to create a list of string, a list of numbers, a list of customer, list of whatever. And now when I add the item, if I say it's a list of string, but I add a customer, it's not going to build. I'm going to get red squiggly because I broke the rules. If I say it's a list of string and I try to add a string, of course that's going to work. So just to show you that real quick, let's run back over. We'll paste this in and now I can say let's pets equal new list of string and then we can come on in and watch when I do pet ad there's my ad. I can only add a string. Now watch. I'm going to put number here. Now you can only add numbers. So if I try to add a string, it's going to go red squiggly on me. Zero code added for the generics off to the right. This is a compile time only check, but it's really powerful if we add an interface to combine these to wrap up here called customer. Now if I say a new list of customer, what can I add? Only something that satisfies that interface a customer. So now I could add an object. I could ne it up. Well, I can't know it up. It's not a class. Sorry, I can't in this case, but in this case we could do this and there we go. And now I could add in the type of customer into my list. So this is a really powerful concept. It's not something I use every single day. But if you work with certain frameworks on libraries, react, for example, react if you use TypeScript, use the generics. If you work with Angular for sure usage Eric all over the place. In fact, energy will get back to your question here at the end. And Observables, for example, Angular uses observables and they use generic for that. Alright, so that is an example of what generics can do. You can even use generics with functions. You can even have a function of type T where we don't say what the parameter is. This is a template, but as a developer, I could do this. I could say process data of number. Now we know we can only pass a number into this. That would be another example of a generic, and then it would kind of be like writing this code right here. But now we can just reuse it. I could say process data of string, process data of number, process data of whatever you want. Really, really powerful. All right. So to wrap up on this and then we'll do a final wrap up here and take any final questions. So generics provide reusable code templates. They're definitely not something you have to use. So if you're new to this and you don't feel comfortable with them yet, don't feel like you have to. It's just like interfaces and types. They're optional. You never have to use any of this stuff. However, it's kind of like the Batman tool built. The more you know about this and interfaces and types, the more tools you have at your disposal provides more flexibility when working with types. As you saw with the list of string, list of number, list of customer. You can use it in many different ways, so you only write the code once, but you can reuse it. It's only compile time has nothing to do with runtime. Generics are not a JavaScript feature. They're TypeScript feature and then you can use them with classes. I showed you that you can use them with functions. You can use them in variables like arrays. There's lots of ways. And one of the reasons you find generics use is a lot of times when people don't know what a data type is for a function. For example, they'll put any but when as soon as you do any, you're stepping out of TypeScript and kind of into the realm of JavaScript again in any means what it says. It can be anything. And that's not so great if you're using TypeScript because we want the guard rails. That's where again instead of like a list of any because I could have made a list that just takes anything. But then you're not going to get the nice and tell sense, whereas with the list of bracket, string or number, I can use it in many different ways. So it gets rid of that any keyword. Now code samples of this stuff. Let me show you a project really quick here. I'm going to give you a link to the slides in just a moment as we answer questions. I'll leave that up. But this is a repository I use and all my workshops I do at conferences and things like that. You are free to take anything you want from this. There's a ton of demos in here. I'm going to show you really quickly, just the structure of it and then we'll take final questions. Alright, so before we go to this slide, let me just show you this project. So if you go to that repo, I'll give you the link again to the slides in just a moment, which will have a link to the repository. You'll find examples. This is where all the examples are. Lots and lots of examples in here. If you want one, that's pretty robust. This is from a TypeScript course I have here. There it is. This object oriented one solution. This is a little more robust project that uses interfaces and generics and all kinds of fun stuff in it. If you'd like to run that to run these like this one. If you go to the solution, if you see a read me just follow the instructions in the read. If you want to run the general demos, all you have to do is NPM install and NPM start super easy and you'll be off and running. Okay, so to get to all of that, you can go to this link here. This is going to get you to the slides. The slides will then have the link to the GitHub repository and you can check that out. All right, so let's go back to questions here. So Indra you've been patiently waiting. The question is, what are observables and promises? What is the difference between them? So this is a little outside of the scope of interfaces, but I'll address it real quick. So an observable let me back up. Let me give you a story. Let's say we are sitting on the side of the road and we are watching cars go by. I think you would agree that's like a stream of cars, it never ends. Go to your favorite road. Sit there today and it's just car. Car, car, car. We are observing multiple cars. Now, if I said to you, energy, yell out to me. Anytime you see a red car, then the green one drives by. You ignore blue one drives by, you ignore red one drives by Dan, there's a red car. You're observing the car. So observables allow you to observe multiple pieces of data over time. A promise allows you to wait for some data to come, but only one piece of data. So what I mean by that is it would be like I say, go out to the street and watch for cars. But if it was a promise, you would wait till that first car comes. So it's asynchronous you're waiting. The first power car comes and then you're done and then you walk away. Whereas an observable first car comes, you see it, second car comes, you see it, third car comes, you see it. So it's almost like a pipeline and the cars are driving through the pipeline and you can look into the pipeline with observable. You can see all the cars if you want. With the promise, you get back one asynchronous value. Now there are other differences, but hopefully that helps you out a little bit. Stream of data. That's observable is a stream of data. Okay, sometimes API returns name, but the interface has a name property causes customer, not still customer name. How do we prevent this? So you have to make I think what you're saying a non attendee is in fact, let me just let me see if I can drag this over and then everybody can see the questions easier. I don't know. Actually, Zoom probably won't show this, but if you can see it, great. If not, I'll just read it again. Sometimes the API returns name, but the interface has a name property to customer name not filled. Okay. Yeah. So first off, with an interface, everything's going to be case sensitive, because I see here that you have lowercase name and uppercase name. So whatever the interface says, if it was lowercase name, it has to be lowercase at runtime, though, if they don't pass you a name, interfaces won't help you there, because remember, interfaces are only at development time. So at runtime if you're expecting a name, but they didn't pass one TypeScript is gone at that point. Now you're just in the JavaScript world. So now you're going to have to write like an F, check a conditional or something, so there is no help there. Now what you can do at development time is, of course, if you do customer dot name, you write an if statement to say, if customer dot name, then do something, then the customer name park could be part of an interface, and it could be optional. Could have a question Mark. But again, that's not going to help you at runtime with your API, because at runtime, it's just pure JavaScript. It's not type script. Now, if that's not what you're asking, just re answer or as that in maybe a different way, as I might have missed what you're asking. But is this possible type A interface type two interfaces. You should be able to I don't know why you couldn't. Let's try that real quick. That's easy to demo. Here's the question. We have an interface and the answer should be definitely yes, I can't say I've tried that recently. So I'm just gonna we'll try it. And the question is, you have a type called I don't know my type and it is customer food, and that should work fine. And it does. Now I could do let object. And now I can make it a customer like that. Or I could just make it satisfy the second part of the type. And that would be like that. You can definitely do that. And that's first off. Great question. This tool that you see this playground. That's usually where I'll go if I have these types of questions myself, because there's stuff I don't do every single day. That's one of them. I haven't tried that exact scenario recently because I could also do this just to show you. Instead of even making a type, I could have just done this. I could have said the object itself is a customer or a food. But if I find myself doing that a lot, we'll just pretend this was okay. Let's call this OBJ two. Then I would probably say, oh, we're duplicating code. Let's just make it a type, and then we would do this. But anyway, to answer those types of questions, I just run the TypeScript playground. Then I even have to fire up a project. I could just do it really quick. Great question though. Okay, let's go back can we combine them type in interface? Well, an interface inside of it could use a type. That would be. Okay. So you could have a property of type some type, but you can if you need primitives and interfaces like I showed earlier, you'll have to use a type. So yes, you can mix and match them. We just showed using a type with two interfaces, so that's a mix and match. But an interface can also have a property in it or even a function return type or parameter. That is a type type when I say type. So yeah, you could definitely do that. Is this possible? We just did that one. Okay, Benny, from benefiting from your designing coding experience, how likely is the snare where an interface with generics? A lot. A lot. That is something I have done a lot where I actually will have, like, a list of like I did earlier. I think I deleted that. Unfortunately, let me see if I can undo real quick. There we go. Right there. So this right here could be anything right now. Right now, you can even get tricky. And I could even say you can pass me anything as long as T extends customer or implement customer. In other words, that's a little more advanced feature. What I wanted to show you was this here's an interface. And now I'm using that interface to say what you're allowed to add. So, yeah, that type of combination between generics and interfaces. I do a fair amount. But again, this could be a class as well. Right. We have to because I have initialization on as a setting. I'd have to do something like that, which, in this case, we could just do that. Now, I could do that too. But now you're going to get that class shows up in the build. Maybe you need it. Maybe you don't. In this case, if I never knew it up, I would prefer to go with either an interface or a type in that case, because it's just an object, and that's all it's ever going to be. I prefer interface in that case. But whoever asked the question earlier on, should you just always use type go for it. I can do the same thing. So again, it gets down to personal preference. Okay, let's see here how to use generic with an arrow function declaration. Let me see if I can think of a good example of that. So if we had let F equal actually, let me go back to a function declaration. A generic here. Yeah, I'd have to think through an example because with that, if you had a Pram and then that just let's just call it P like this. Well, I'd have to give it a data type. Well, just for now, cheat and I'll do any. Don't try that home, kids. You can do that. But anytime you do any, you're kind of bypassing the system. In this case, I'm trying to think right here because normally you'd have a function of T like this. I don't know that you can do that here. I don't think you can. Yeah, I'd have to think through that now. The parameters and stuff that would be a possibility. I don't think you can do T here. No, I didn't think so. Yeah, I have to think through that's a great question. I don't know if I have a great answer for you. I have to think through a specific scenario to be honest. So I'm going to have to say on that one. I'm saying I'm not sure. Good question. I'd have to think of this scenario. If you have a scenario you're thinking of, let me know. All right, Lucy, if the use of any okay. In transition. Absolutely. In fact, Lucy, that is a great use case right here. If you move this, let's say this was your JavaScript and you're moving this to TypeScript, and you're just trying to slowly migrate your code. Well, one option is in TypeScript. You have your TS Config JSON file, your compiler settings. One option is you could just turn off all the strict stuff initially, just until you get your code started. But if you don't want to do that, absolutely. You could come in and let me go back to here and you could just say for now, I'm just going to make this in any and later. We're going to come back and fix it in a perfect world if you knew this was like an object, like a customer. But you just right now don't have time to either write the class or the interface because you just want to get it working first, then. Yeah. Start with any and then gradually start to add in the TypeScript code into it. There's nothing wrong with that. And that's what's so nice about type script. You can use as much of type script as you want or as little of type script as you want is totally up to your team and you. So that's a really good question, Lucy. All right, Dana, can we use generics to specify a set of aloud types for a function? Well, if you're going to say aloud types for a function, normally, that would be a type or an interface. Remember, generics is all about types, but in a code template. Now, I suppose if you wanted to be able to do something like this, I'm not saying this is a good idea, by the way, but you could. Okay, now the problem with this, you see, the plus cannot be applied to T. And the reason is this if I did add in past five or five and five here, we should get ten. Right. That should work. Right. Get rid of that. But what if I pass in? I didn't finish my generic. Let me back up. So if I do this, if I did number and past five and five then that should work, right? Yeah, it should. Or if I did add string and pass John, and so that should work, because in JavaScript you concatenate strings. What if I did this? Well, I have to do two of these. I'll just paste here. Grab that. Would that work? Okay. So the first thing I want to talk about what functions is if you ever plan on trying to use it for this type of scenario where it's a plus operator. You can't, unfortunately, because it would work with numbers, and that would work with strings. But how would you add to customers together? You wouldn't. You can't. So going back to your question, though, Dan, I wanted to clarify that first. Can you use generic to specify a set of a loud types? Yes, you can, because I just kind of showed that it just you couldn't do the A plus B, though I could do something else in here. I could just log A and B logged. I could do that. Now you can control what the parameters types are. They could be number, they could be string. They could be customer in this case, if I had a customer. So yeah. Now I would argue, though, if your goal is to control these and you don't have template code down here that you're using the data types, you might be better off using type or an interface right here. I'd have to see your scenario, though, but hopefully that discussion I just did helps a little bit. Okay. Answer and Boris will say best for last year. How do you do type check on runtime and easy. Generics? Yeah, it'd be a type of actually, generics has a couple of things. Let's go back to the ad here and let's do one thing that comes up is if you want to initialize a variable such as food, anyone initialize it to the default of whatever A or B is, how do you know what A or B is at this level? We don't know T is unknown. Now, if we came down and said add a number, well, now we know what A and B is and the default would be zero of numbers. But if it's a boolean, we pass boolean here. What's the default of a boolean? False. So a little trick you can do this doesn't answer your question. I just want to show you something real fast here. Is there's a little trick you can do? And in this case it's expecting the expression. So don't worry about it. Be default of T. Basically, there's a way in other languages you can get the default in TypeScript. They don't have that. So to answer your question, you can check data types. So you ask type of. Normally you would say type of A equals, you know, string or something like that. Your question was type of T. Here's the thing. When does the if statement run? When does the if statement run? You always have to think about this in TypeScript. Well, the if statement runs at not compile time. Runtime. Is there a T at runtime? You can answer that right here. No, there's not. So this is going to be different, I suspect more. So you've probably done this with those languages. You could check a at runtime to C, but you can't check the T here because at runtime there is no T, and that's the important thing to know here. But you could check the parameter or the variable or the object or whatever you want. So that would be a viable option there. Okay. Answered function maybe come to. Yeah, let me try that. That's not one I have tried, but let's try that. Yeah, let's see here. Now, if we do, we call food of string. I guess it would be we have to pass food as a string. Yeah, it looks like it does. That's interesting. So that's not one I've done. So there you go. But it looks like that is odd syntax. I'm not going to say I like that, but yeah, it looks like that works. Let's double check. Let's say it's a number. Yeah. Okay. Yeah, that's a bizarre syntax, but that is not one I've tried recently. Anyway, I'm not even sure I've seen that recently, but yeah, good research there. So thanks for sharing. There you go. There's your stump, your teammates question for the day, folks. See if any of your teammates know that one. I'm going to guarantee most type script. People probably don't know that one a little bit tricky, so. Yeah, thanks for sharing. That. Okay, why even have generics? What benefit does add to even give us? Well, the ad one was pretty primitive. Who asked that? Was it Ben? Yeah, Ben, the ad one was pretty primitive. I would say the list one is more reasonable. I'll show you a better example, though. In other languages, a good example would be. Well, let's not do the language. I'll tell you what. Let's do something at you. All use in JavaScript. Promises are observables. If you had a function, call get customers and you don't pass anything in, but it returns a promise. Okay. What data type? Look at the code over here. Now, this is built in to TypeScript. What I'm going to show you here. What type of promise are we getting back? In other words, it's called get customers, but are we getting back like an array of numbers about customers? Is it actual customer objects? What are we getting back? Well, if we had a customer type, I'm just going to leave it empty for now. I could do this. And now whenever I return, I have to do my resolve. Reject call here. I'd have to use promise to do that. I'm not going to write that. But now whoever calls this when they call get customers dot, then what do they know they're going to get back here? If I fix this. Let me see if it'll let me return. No, I don't know if it'll let me yet. I don't like that. I need to return a promise function, but we'll just pretend we did resolve recheck. Now in the ten for the parameter here you're going to know it's a customer object. Okay, now there's R1 life example. The same goes for those doing angular with observables. There's an observable of T built into angular and RxJS. It's called that's just built into the libraries. So there's two real life examples with asynchronous processes where it helps you know what it is you're waiting on. And of course on the promise one he could have done in a wait if I had an async function. Now when it comes to you as a developer and writing generic functions, it really would depend. Maybe, for example, though, you have a add invoice line item of T and there's different types of line items that you support, and then when you call it, maybe you this time want to pass a customer. So pretend I passed a customer object for the line item. Here's another one I want to pass apart for a car or something as a line item. Now I'm kind of stretching here. I will admit, because I'm trying to quickly answer your question, but the observable and the promise that'd be just one of many ways array would be the other example I showed you. That would be another one where you could use generics. I don't actually like that syntax myself. I prefer to do that, but some people like the other syntax, but that's a real life example. A be a colon there, but that real life. This would be another example of your own custom function observables problems. I can go on and on and on, but hopefully that helps me feel free to ask another follow up if that doesn't help, but alright, well, that was kind of a whirlwind of trying to get through questions as fast as I could, because I know we all have limited time with that. I'll go ahead and wrap both though, and I want to thank everybody for coming on Plural site. If you're new to type script at all, check out John Pop and I have a TypeScript fundamentals you can check out and then if you want to see generics, there is. I believe that I didn't do that. Of course there is a generic course, I believe, but I have one called object oriented type script and it goes into interfaces and generics and all this type of stuff. So if you are a plural site, subscriber, feel free to check those courses out and they'll give you even more details than I have time in an hour. So with that, if you have any other questions, just reach out to me on Twitter. Just Twitter. Com Dan Wallin and you can ask there if you'd like, I'll be happy to chat with you there. But here's where you can get the slides in the code. And with that, I will wrap up and say thanks for attending. Everyone who's great to talk with you today.