TypeScript Fundamentals

rid Out there. Today, we've got a long time coming show, and, is TypeScript fundamentals. So rid. This is the first of many TypeScript shows that we will have probably over the course of the year, and this one will sorta get you up to speed with what it is, what are the different Parts. What are the benefits? Why do people love it so much? How do you use it? Things like that. And then we'll have future episodes that dive into some of the rid The more nitty gritty, more complex topics of it. Today, we are sponsored by 3 awesome companies. First 1 is rid. Vanity structured content CMS. Second1 is LogRocket JavaScript session replay. And third1 is Cloudinary Image hosting, processing, resizing, resampling, requalifying, everything around images. We'll talk about them partway through the episode.

How you doing today, Scott? Hey. I'm doing good. Getting into a lot of code stuff. Just Working on the the next build of leveluptutorials.com, which is has been a significant project because we're using a lot of, like, really neat future tech in it. Rid So I've just been really, really heads down in that, and we recently decided to rip GEST and React testing library rid Out of the the code base for the front end tests entirely.

Not because of any problem with, let's say, React testing library, but I think I just got so sick of just Garbage on the UI. There was just so much config, so many, like, extra babble stuff that I basically just rid. Had a flip the chair over a moment, and he's like, you know what? I'm gonna rip it out and just go straight end to end testing with Cypress only. So, like, Straight up Wow. DOM testing, end to end testing only for UI.

It's an interesting decision, and we're gonna see if I regret it or not in the future. But to be honest, rid I'm feeling very positive about that choice. So, yeah, a lot of lot of interesting threads that I'm I'm pulling on right now. Interesting. Yeah. 2021 is the year of

rid Config exhaustion.

I had, like, JavaScript exhaustion a couple years ago. What was that called? JavaScript? I don't even know. Fatigue? Fatigue.

Now we have config fatigue. I do have config fatigue. Yeah. Especially as we move to ES modules, and We get a lot of lot more of those annoying little gotchas. Like, the other day, I was trying to import a module into Next. Js, but it re It was only published to NPM as a ES module, and it worked on, like, hot reload, but it didn't work on the server. Ready. And then I tried to, like, dynamically import it with Next. Js, and it wasn't working. And I was just like, this is hard.

All for a couple words of how you export something. Yeah. I know. I so we had

ripped out Babble, so we're not using Babble anymore at all. And it turns out, like, when you're trying to test React code without Babel, things get very, very annoying really quickly. So, Yeah. That that's how it is. But let's get into, let's get in TypeScript here. And I think a good place to jump off would be to first talk about Types in programming in general or types in JavaScript, what are basically types in in the sense that, like, why should you care about rid What a type is, and does JavaScript even have types already? So, types are basically the thing that we know and love For when you define a variable as something, it's what that something is. Right? If you create a variable that's a string, Well, it's a string. The string is the type. Same with a number or an object. I guess, a a function is just an object. Right? What we always do this this, can you name that the types? That's like a Yeah. A a inter interview question that we've done often. Can you name offhand the JavaScript types? Gonna do it again. I'll give you the hard one as symbol. Okay. That's the one everybody forgets. Oh, yes. Symbol is the one I remember. Oh, yeah. So there's String, number,

object, null, undefined, symbol? I wasn't counting, so I'm gonna go with your word on that one. Okay. I think that's all of them. And then sometimes you hear people say, everything in JavaScript is an object, and the reason why it didn't say array or date rid. Or node or anything like that is because all those things are just objects at the end of the day. So those are the sort of the built in types that come with JavaScript.

Rid But you don't have to define that something is a number up front. You just make a variable, and you set it to 42. And if you want to, in the future, Set that variable to a string of Scott Talinsky.

Or if you want to, pass it in to a function where it's expecting a number, but you pass it in as a string, JavaScript doesn't care. That's referred to as loosely typed in in JavaScript, and it's for some people, it's seen as a benefit Just because you can sort of just go get up and running really nice and quickly. But for larger projects or just in general, it can be nice, Especially people coming from other languages to JavaScript where you're used to a language that is typed, meaning that I I guess we'll get into this. But When you define literally anything or when you pass in arguments to anything, you have to say

the type of the value that is being passed in, that is being defined, that is being returned, all of that good stuff. And there's a bunch of benefits to doing that Extra work, and we'll get into those in just a second. Yeah. And so JavaScript does have types, but, like, they're they're useful in the sense of, like, you can Check to see if something is the type of something with type of, but they're really not anywhere near as useful as they are in other programming languages.

What's really interesting is that, like, what JavaScript has 1 number type and 1 string type, whatever. But if you get into other programming languages, Specifically, ones that even get closer to the metal of things, like I'm gonna use Rust as an example here because, it's something I've been in. Rust has read. A ton of types. For instance, they have an 8 bit integer, a 16 bit integer, 32, 64.

Same thing with, like, even, like, Strings. You have to define, essentially, like, what type of a string something is, whether it's, like, a, string slice.

They just have so many more micro types that deal with allotting things in memory. Rid. But in JavaScript, we just throw things in a bucket. It's a number. It's a string.

It's a object, whatever. Let's get into the the fundamentals of Type script itself. I think in this episode, we're gonna deal more with high level, big picture things rather than, like, syntactical, small picture things. So just Keep that in mind as you're listening. We're not gonna get too in the weeds here. So the fundamentals of TypeScript is really that you write Your code the same way that you would write your JavaScript code. There are some files for me even when I write my JavaScript code Or when I write my TypeScript code, I should say, it is no different than my JavaScript. They are the exact same file Yeah. Because TypeScript is really just JavaScript with extra features where you can define your variables. You can define your functions, whatever.

Only this time, you can say, alright. This variable is always going to be a string.

Or in some cases, TypeScript, which we'll get into, will know automatically that this thing is a string and will always be a string, but you can also define your parameters in a function. Hey. What what parameters Does your function take what are they? What types are they? This function is always going to take a string, so that way when you pass a number into it, TypeScript's gonna get angry. Rid. The same thing with your return types. What is this function return? Is it gonna return a string? If it returns a number, then TypeScript's gonna get angry. Yeah. So I I think that's important that what you said is that all JavaScript

is TypeScript. So you might be, like, listening to us never having a thought of rid Trying TypeScript before. Oh, god. Another language. It's not another language.

It's just JavaScript, which with I like to think of it as metadata about your code added on rid. Yeah. So Yeah. That's a nice way to say that. These are instructions for when you have a function, what it's gonna take in, What it's going to return, and that's really helpful. We'll talk about the benefits in just a second, but you don't have to necessarily look up documentation ready for what a function takes, what parameters are on an object. A lot of that stuff just happens inside your editor now, which is really, really nice. I think that's the the killer feature. That that's what really usually turns people over is that they're starting to type something, and all of a sudden you're like, oh, it knows rid What properties are on this object? Or it knows I accidentally passed a number, and I didn't have to go to the browser to figure out rid That it accidentally like, I was I was in my tutorial recording a tutorial the other day, and we're just using JavaScript. And rid I was adding some numbers together in it, or 2 plus 1 or for whatever. There was, like, 2 items in the cart. We added another one, rid. And, it had 21 items in the cart. So you can expect what happened there is that the number of items was stored in a string, and then we used plus, And it concatenated the 1 on the end instead of actually adding it. So, that kind of error would never happen in TypeScript because

it knows ahead of time what the types of your values are. And another thing to add on to that is you gotta think about that as a kind of offloading some things that would typically be placed on the shoulders of Either your users or your developers who are writing and testing the code to discover those kind of issues. I I granted this was kind of a big error, so you could see that pretty Clearly. Yeah. But if you were kind of fair about it or you made some, like, changes here or there, and all of a sudden, somebody didn't correctly test that or tested in a very specific way or manually look at it. That code could really hit your users without you even knowing. And so I like to think about TypeScript as being a way to sort of offload a bunch of tasks that normally I would have to do manually. I'm offloading those tasks onto the shoulders of the computer Because it does those things really well. It's able to really identify the issues that we would have in the type situation like that, like a type error that you could ship to your users. It's able to identify those instantly as you're writing the code rather than that error ever making it to the users or even having to have that cognitive

rid load of having to remember to test stuff like that. Totally. Like, another really good example is if you accidentally spell something wrong, rid. TypeScript will throw an arrow. Oh, yeah. Like, for an example, I've been working with TypeScript and, like, a a shipping platform.

I'm taking values in from Snip rid and trying to generate some shipping labels. And just little things like wait or dot like shipment dot customer dot shipping address. If you forget the capital a on the camel case shipping address, little things like that where you just assume it works fine. I mean, you might not even catch it, Or you have to catch it when it's in the node console or something like that. Those things will immediately read underline in your editor and say, hey. Rid. You try to access this property shipping address, but it's that's not actually a thing. Like, maybe you meant shipping capital a address, or rid. Maybe you meant something else, and you can go ahead and check it. And then also, like, properties on that object will also autocomplete, so you don't even have to Copy paste the the typing or, hopefully, hope you get the typing right. You just hit enter on your editor, and it will show you that. Yeah. I think that's a big point for people who rid. Might be on the fence about TypeScript here. It's really just like

the benefits do come in with the TypeScript compiler. Sure. It prevents your code from being compiled Or can, I should say, prevent your code from being compiled if there's type errors? But to me, one of the biggest benefits is really just that information's there in my my text editor while I'm typing my code, And I can see exactly if I did a little goof up like that in my code without having to run the code to find out that I did have some little goof up like that. Those kind of things happen way more than you think. So some of my biggest wins have been with, which we'll get into more in this episode, like rid. Enums and string unions. So those words might not mean anything to you at this point, but it allows you to, like you know, if you ever do any string comparison, is the string equal to that ring. It allows you to really, like, dial in some of that stuff. That to me, those those benefits are just really, really big. And you're also going to see some big benefits with one of our sponsors, and I'm talking about LogRocket. Now LogRocket is the service that allows you to really see Just how your errors happen in real time, via a scrubbable video replay. It's one of these services that before I heard about this, I just had never thought of something like this existing. You you think about your classic, You know? Okay. Here's an error. It's in the log. You can look at that log and look this up. But this is a service that actually allows you to see a video replay of the error And to me, when I I first saw this, it seemed like science fiction to me. Not that, like, the tech was this out of this world, but it was just something I had never even considered Existing, being able to see the users, actually commit the atrocity in real time. They clicked on your logo 10 times and your whole site red. Turned red. How did that happen? I have no idea, but now you can find out with LogRocket. Head on over to logrocket.comforward/syntax, and you will get 14 days for free. So thank you so much for LogRocket for sponsoring.

Okay. Let's get into types themselves.

Yeah. So let's explain the base types, And then we'll get into both custom types and types that come along with NPM packages because I think that's why a lot of people are jumping on the TypeScript bandwagon now is that these types are re Finally, very much available, and it's it's easy.

So just like in JavaScript, there's a set of basic types. So you've got rid. Strings and numbers, those are probably the 2 most basic ones. Strings, they're just text. Numbers as as any number. There's no difference between floats and integers.

Like Scott said earlier, we do have BigInt as a type just as we do in the browser, but, like, most people aren't going to be using BigInt.

Rid Like, I think a lot of graphics folks use it and probably a lot of banking people, if you get into some very, very large numbers.

Then we also have arrays. Arrays are not a type in themselves because an array is just a A list of another type. So you could have an array of numbers, an array of string, an array of shipments, an array of people, an array of shows, Etcetera, etcetera. So these are these are, like, sort of in addition

to defining, like, a type. You can also say that something is 1 or more types. Like, for instance, sometimes a variable is a string or potentially null. Right? If it's not set, it's undefined.

So this string, it could be undefined. When it's not set, it could be set to null, or it could be a string. And in that case, you use something called a union, which is The vertical line on your keyboard, it's the one that's directly above the enter key. I think you have to you have to hold shift it to get it. But it's that vertical line that basically The pipe. The pipe. The pipe. Of course, the pipe.

It basically means an or in this kind of situation where you would say rid This is a string or it's a null or it's undefined. And that way, TypeScript isn't gonna freak out when you say let rid value and then define it later because, well, value can be a string null or undefined in this

While we're on that sort of idea of it could be a string, but also could be null or undefined, in TypeScript, there's an option you can turn on, and rid. It will make you account for those situations.

Like, if you have a function that returns the upper case of a string, You can just code it, like return name dot to upper case, and TypeScript is gonna yell at you and say, hey. You did not account for that String being undefined. Mhmm. There is a possibility that it could be undefined. Oh. Like, what a pain in what a pain in the it's not rid. Gonna be undefined TypeScript. It's not. Believe me. I promise. It'll never happen. Yeah. And then and then it happens, and you go, like, rid. TypeScript makes you be a little bit more verbose with your code. And if that's the case, then you have to go into your function and And actually check if that value is there before you go ahead or put a case in for when it is undefined, then do this. Rid. And, initially, that is a turnoff.

Still is a bit of a turnoff to me because you can certainly turn off that that type of thing. But, rid. When I'm looking to move fast, I'm just like, TypeScript. Let me, like, let me just go faster right now. But, when you're writing, like, software that's gonna be around for more than 3 hours, it's rid. It's a good idea to have to force yourself into that that use case and say, alright. Well, if it is undefined, then we won't actually run to upper case on it. Imagine how

Awful TypeScript code was, Wes, because I know you didn't write a ton of TypeScript when this wasn't a feature, but when before optional chaining was added to TypeScript, rid It was a giant pain in the butt when we were refactoring our bunch of our code because every single time you hit one of those objects is possibly undefined or null errors or whatever.

Rid Oh my god. You have to go through the whole rigmarole of checking every single thing rather than just being able to do a question mark, period. Sorry. I don't I don't wanna get too into the weeds and stuff like that, but that was a tremendous pain. And now we have optional chaining to make that nice and easy. So much easier. Next one we have here is intersections.

Intersections are kind of like unions. Unions is like well, it could be one of these things or one of these things. Rid. Intersections will allow you to combine multiple types into 1. So, most likely, you'll have, like, a user response, And then you also have, like, an error response, and you could combine those into a single response. Or if you have, like, 2 different types and you wanna combine all their properties into 1, you can intersect them. I don't use that as much as I do the union, but it uses the ampersand instead of the pipe or that union does.

Word. I mean, you can almost think of the, yeah, or and and in this sort of situation. Yeah. So, next one would be objects, and objects, They're objects. Right? Objects have properties inside of the objects are going to be properties that have types themselves, and these can often be defined as their own type itself.

Rid self, you could say type or interface, name it as something, and then define the values inside of the object. You can also just define the individual properties in the object, Or, you know, you can just blanket say, hey. This thing is going to be an object.

Now granted, I probably wouldn't do that because that's not very descriptive. Right? Rid. If you say it's just gonna be an object, it has no idea what's going to be in it. And the whole idea with TypeScript is that you have to tell it ahead of time rid What properties to to exist? There there are a couple workarounds. Like, I have, like, a little interface in mind that rid. Is like a metadata interface or a random interface where sometimes you don't know what the properties are ahead of time, and you just say that rid. There is a key, which is a string, and the value can be any, which leads me to the next type. There is an any type. Re Any is a type in TypeScript that can be literally anything, and it's a bit of, gun, I guess, rid. Because when you type something as any, you're essentially saying bring in any type in this case, and and you lose a lot of the benefits To TypeScript there because then you don't know what methods are gonna be on that type, what values, what properties are gonna be on it, what you can do with that thing. But there are some legitimate use cases where you don't necessarily know what the thing is coming in, or you're using some sorta, like, rid. 3rd party library that is massive and has no types, and you can just stick in any in there. So there's kinda like 2 different types of any. There's explicit any, rid And that's where you'd literally type with your keyboard any, and you're saying this will be any. And, generally, most people allow that. And then there is something called implicit any, which is when you're writing a function and you don't type, like, an argument, it will be implied that that value is any. And most people will turn that

off, meaning that that will stop TypeScript from compiling entirely. Is is that what you do, Scott? Yeah. That's what we do, rid. And and it can be really, really painful if you're moving a large code base to TypeScript Yeah. To have implicit any on it first. So let or rid Not allow implicit any on at first because that's what when we first transferred ours, we you know, you have a 10,000 typescript error so that rid. What we did is we turned no implicit any off, so that way we wouldn't have a 1,000,000,000,000 errors. We took care of all those errors, and then we turned no implicit any on. So now we can remove any implicit anys that we had after that just so we didn't get rid. Totally overwhelmed while we were doing it. But at the end of the day, I like to think about the using any as basically putting up a white flag and admitting defeat. Rid. If I'm typing something as in it, it means that this thing has frustrated me to the point where I cannot figure out what the type should be, and and I almost re Always use it as a last ditch effort to just get my code to work. It's the important of in CSS, we have important. Oh, yes. It's rid. The same same idea. You're like, ah, it shouldn't be really be be really doing this, but, like, I gotta get this thing shipped. Yeah. Yeah. And It will probably bite me down the road, but right now, I don't care. Yeah. And anytime I type things as an any, I almost always put an at To do comment next to them or above them, like to do or come back to this type later, which, of course, we all know.

Rid It's just a a, you know, window dressing there. But if you have a to do in the code, there is at least like, it makes it easy to find your, You know, command f to dos in your code base, or, we actually have, like, a Versus code extension that turns our to dos into, like, little checkboxes rid is in that little explorer on the side, so it makes it easy to find them. I would say just don't don't use any unless you absolutely have to. It's basically saying, hey. I,

TypeScript isn't gonna care about this. And, well, what's the point of using TypeScript if it's not gonna care about your stuff? Rid Yeah. I like that you talked about it in a use case of, like, moving over an existing code base because TypeScript is much easier when you are coding something from scratch. Oh my gosh. Infinitely. Yeah. Yeah. So maybe we'll do a whole show on, like, how do you do that? And, also, I think I don't know if this will be the same show or not, but you can also get, rid. Like, 92% of the benefit of TypeScript by writing JS doc in rid Dot JS files, we'll we'll talk about that in, in a future show, but it it's pretty pretty nifty. Yeah. There's a lot of topics. Yeah. I that's why I'm, like, rid. I'm glad that we're doing this one because

we have so many, like, little TypeScript hasties and tasties that we wanna do, but we thought we should get the The fundamentals episode out first. So the next one here, it's it's funny. I think West said labeled this as language types. I don't know if these actually have a name, But these are really just things that are types that sort of exist within the language of JavaScript itself or in the DOM itself rid that are just there in TypeScript, as in you don't have to import them. You don't have to type them yourself. And these are things like date, so you can define the type of a date Just like you would a JavaScript date. Right? And that's not necessarily like a is that a type type? Oh, I don't know. Rid It's not a type because it it's a capital. You no. You can type it with lowercase d date in TypeScript. Mhmm. But it's at the end of the day, it's just an It's really just an object like like most other things are in JavaScript. Yeah. And so these things are all have their own properties. Right? We all have these primitives in in JavaScript where there it is for, like, know, you set time out methods or something like that. And there's also, like, DOM elements and notes. Think about this in in React. Right? You maybe place a ref onto something, and that is an input.

And an input, based on what rid Type of input it is can have all sorts of different properties.

So built into TypeScript is the ability to define things as what they are in the browser as HTML DOM elements, Specifically down to the type of input. Like, I mean, you could have, you know, HTML I believe it's HTML text area is the type for their text area. Yep. They have basically exist for all of the different types of DOM elements. So that way, you're if you're referencing a DOM element in JavaScript, it's gonna know all of those sub properties that that element has. Yeah. If you're using, like, vanilla JavaScript or or even React reps Yep. It's really handy to get all of the method and property completions

rid For the different types. So if you do, like, query selector, like, video dot player, right. Right now, if you only select the element as dot video, it will infer that it's we'll talk about that as in a second. It will infer that it's a a video element. Otherwise, if you give it like a class or something, it'll just give you the base type, which is element.

And that doesn't have, like, Methods like pause and play and current time and all the other properties that an, a media element would have. So you can type it as a HTML video element, and then you get all the auto completions and all the properties, all the methods that you would from that thing. And it's it's awesome. So usually have to go ahead and explicitly type those, both in React as well as vanilla JavaScript. Well, I'm gonna give you a little bit little bit of a Versus Code tip here. I don't know if you know this keyboard shortcut, but control spacebar,

what would do you know that do you know that shortcut, Wes? Yeah. That that's code reactions in Versus Code. Right? Yeah. Well, it opens up your your auto completion, basically.

Let's say you did a variable that is an HTML type, and you did The variable dot, and you wanna get those methods. But the code completions or any of that the types, the stuff the the methods aren't coming up on that, You can always just do control space bar, and it's gonna pop that open. So that way, you can see exactly what exists on anything. So if you That's a good tip because I often I see people, they just delete the dot and then

type That's a good tip because I often, I see people, they just delete the dot and then type it again. Yes. Yes. Exactly. That's that's what I'm saying. Just just to get that to find I do that myself. So that's sorry. That's not That's not code actions. That's just the Versus code autocomplete.

I also have, hyper h hooked up to that, but for Arguments to function. So it'll tell you what type it's expecting in a when you're passing in a function. So if you if you're running a function called, like, rid Ship item. You hit hyper h. It will tell you it's expecting a shipment type,

which is really cool. And that can work too if you're defining properties inside of an object. If that object is typed and it knows what those parameters should be or even, like, in a function parameter and you wanna see, like, what arguments you can pass into a function, If you're inside of that function and you do control space, it's gonna pop open with your options there. So another way that, like, TypeScript is let them, like, yo, I got your back.

Rid I know what know what types are expected here, and if we pop that open, it's gonna let us know. Next one we have here is void. Void is used. We we had rid. Entire show about nothing. You can go back and listen to that. But, essentially, void is when nothing is returned from a function, and that's usually used when you have, like, side effects like a Click handlers. And sometimes people have rules on their functions where you must explicitly type that a function is void if it does not return anything. I And some people will just not have that off. So if you don't explicitly return a value from a function, then it would just assume or it will infer that it is void.

Nice. Yeah. I use that just about all the time in React because oftentimes you're passing a set state function into another component, and those set state functions, You don't care about what it's returning from them, so I always type those as it's a function that returns void. The last thing that we're gonna talk about in this section at least is going to just be enums where, re an enem is basically you can think of it as like a set of named constants is the best way to describe that as in, like let's say you have a set. Like, this is a good Good example here. Okay. We have we have the syntax f m show, and we have the hosts.

And the hosts can only be Wes or Scott.

Well, if you try to define that variable as anything other than a string of Wes or Scott, you could say that this is going to be rid. An enum and say that the options are a, Wes, or Scott.

And to do this, you can do this with enums or also what are called String unions, where we talked about unions before. Well, you could say that the type is also a union of this explicit string or this explicit string. So there there are definitely, like, camps of people who will use enums verse string types, and there are string unions, and then there's people who use string unions verse types.

I personally use the enums. I don't know necessarily why I do. They're a little bit more explicit, I would say, maybe a little bit safer. I don't know if that's really an argument I can make rid Because for the most part, string unions, where you're saying it can be these values or you're saying enums can be these values, rid This basically is doing the same thing. I like to think of these as the select lists of TypeScript. Yeah. Oh, that's a great way to put it. Yeah. In HTML, you have select lists where you have the values and you have their Display values, but also their real values, you can do that with enums as well. And, we all know that working with string comparison could really make you go bonkers, but rid. One of our sponsors today is going to bring you some Sanity. I'm talking about Sanity at Sanity dot I o. Yeah. Sanity

dot I o is rid The structured content CMS for your next project. So, hey. If you're doing your next project in TypeScript and Maybe it's a React application or Vue application or or literally anything that you need a back end for. Sanity is gonna be what you want. They rid. Had an awesome year. They rolled out all kinds of really neat features. They just did this really cool 2020 in review blog post. They added collaboration. So, rid Like, besides developer experience, Sanity has amazing like, the collaboration.

The the part where the end user actually manages the content rid It's very, very good. It's called Sanity UI. You can customize it all you want with your own React components.

Your data just rid. Comes out in an API, which is really cool. You can use GraphQL with it. That's what I use on one of my courses. So if you have a project you wanna try Sanity on. Go to sanity.ioforward/ syntax. That's gonna get you double the free usage tier. Thanks so much to Sanity for sponsoring. Sick.

So let's get into inference here. Now we're referring to the ability for TypeScript to automatically infer what TypeScript doesn't know what yo is. Right? It has no idea. So in that kind of situation, you would say let yo colon string to let it know that it's potentially or it's going to be ring. Right? Or or I guess it would have to be at least potentially undefined as well at that point. But let's say you said let yo equal to And then a string of Scott. TypeScript is smart enough to know based on that definition that yo is rid Always going to be a string or should be typed as always going to be a string because when you're setting it to be a string, it knows that,

re Hey. It was initialized to be a string. Therefore, I'm a string. Hey. That's what I am. Yeah. Yeah. That's that's really key because you don't have rid. To explicitly type every single number, string, type that you possibly want because that's that's a whole lot of extra typing that you don't have to do. So TypeScript will infer a lot of that for you. You can see that by just hovering your mouse over your variable, and it will show you the type of it. Rid. That is also true for custom types. So if you have a function that is called, like, generate shipment, and that Function, you will type it as it will return a shipment or it will return a promise that returns a shipment. And we'll talk about that In a future episode of doing promises and flow control, then you could say something like const my shipment equals await get shipment

rid Or generate shipment, and it will know that the value that

is in that variable that you've created is a shipment. There's no need to go ahead and explicitly type it. Rid. In that case, since it's a custom type, a lot of people will type it anyways because that allows you to explicitly say that you could just look at the code and know that it's a shipment. You don't need to hover over top of it. And then also if you were to change that function, then it would break because you were still expecting a shipment to be in that variable. But if the function stops returning a shipment, then you can tell it. So a lot of people will just say, like, if it can infer it properly, rid I'll stick with that. Otherwise, you need to explicitly type it, which is you write the type colon, the name of the type. Yeah. Initially, an argument to be made that, like, explicitly rid Everything is

somewhat safer.

I I don't know necessarily deep enough if that is necessarily the case. I use implicit re Typing wherever it is. Like, I rely on my editor basically to tell me where something needs to be typed. It lets me know if it's any or if the it's clearly not getting the right type. Rid I do rely on the type inference. Other people like everything explicitly typed. They're both valid use cases. In fact, TypeScript is not the only language with type inference, so this is, like, common amongst type languages or at least it exists amongst other type languages.

Let's talk about getting types from packages because read. That is a frustrating aspect of TypeScript for a lot of new developers.

You install a a package. They did not define types.

You load it up, rid. And your editor is immediately letting you know it does not have types for this particular package. It does not recognize them. You have couple ways around that. The, like, rid Cheapest in, like, least useful way around that is to define it as a module and say rid It's typed if any. Hey. That's the sweeping and out of the rug equivalent of adding types for a third party extension that you don't want to deal with. I think rid. I said this earlier. I think the reason why TypeScript is getting really popular is that most

medium to large size modules will have rid Types in them. Like, people get so annoyed that there are no types for something that they will submit them to either to the project themselves or to rid. There's a whole entire types repo for popular packages out there. And, like, I even went as far to, you know, Cornify, which adds

rid Unicorns to your website? I did not know that. I was gonna say something about the band Corn. Oh, no. No. Cornify is a is a JavaScript package that will add It turns all your r's backwards.

It it well, no. It that'd be wick oh, that's a good idea, actually.

No. Cornify is a JavaScript package that will add unicorns to your website and just overlay them over top. And, I went as far to write types for that and submit them rid the project. And now there is types for that if you install it, which is hilarious. But it is so annoying when a package does not have types rid. And almost a deal breaker in in a lot of use cases. And I think, like, a couple years ago, that was really, really hard to do. But now there are types rid For pretty much everything out there, not everything. Like, for example, I was using Snipkart, and Snipkart has rid. All of the types on their website, they're not TypeScript types, but they're they have an entire page that is every single possible thing that you can get back. I'm sure they have them internally, but I just went ahead and and converted them to TypeScript interfaces myself, which is really cool. So if it doesn't, you have to go ahead ready. And to find your other ones, your own.

And you can also usually, when you hover over top of a package and it cannot find types for that, rid. It will just tell you, try do this. Npm install at types forward slash the name of the package. And more often than not, it will Find them, install them to your package JSON, and then everything will start working. Your autocomplete will start working. Your red squigglies will go away. Yeah. Rid. And, if you have a problem with one of those types or they're incorrect,

well, that's, that puts you in the situation where you have to go the definitely tight monorepo where every single type for every package Liv that that's a rough situation, but that is really what it is. It's a giant monorepo full of all these types, and and when you install it, it kind of just works. You don't have to really, really do anything to get it to to work. It it's built in to work that way. So When you install it into the at types forward slash whatever, it should just find the types after that. Another package I used Is this thing called make types? Because I was working with, again, Snipcart, and I was getting

a purchase back. And that purchase had, I don't know. Maybe a 100, a 150 properties, nested properties of, like, customer, billing address, shipping address, rid. Package, weight, item. So, like, it had, like, multiple properties itself, but then it also linked to other types, which is, like, billing address, shipping address, things like that. And I was like, oh my gosh. This is gonna freaking take me forever to type this thing out. And I found this thing called make types where you just give it JSON. So rid. I just took one of the examples that I got, and JSON stringified it and then dumped it into this make types thing. Nice. And then it rid. It took every nested object and put it in its own type, and then it inferred the name of the type from the property that it was. Rid. And then it will also say, like, well, if it's a number, type it as a number. If it's a nested object, do a custom type. If it's a string, make it a string.

And that was really good. I still had to do a couple Little gotchas here and there for things that were optional properties on the object and whatnot, but that got me, like, 98% of the way there, and I was pretty impressed with that. Yeah. Rid. Anytime anything can generate types for me, it's like a huge win. We have all of our API types and hooks and everything generated for us with GraphQL code generator up and down the And so everything is just in in such a unified manner that our API, our front end code, our React Hooks, everything is typed, but all those types are generated. So we just import the types, and everything knows what it is, and it's so fantastic. So where does that Does it come from your your MongoDB definitions, or, like, at what point is that do you define what is in a type? So that's actually been a point of, Not like intention, but it's been a point of, like, interest amongst us is, like, you're having to think about the flow. It's like, alright.

Rid Everything that's in the API because you can have it generate types from Mongo your Mongo schema or whatever. But, like, the Mongo schema isn't the same thing that's in the API, and then the API isn't Yeah. You don't want the password field to be in part of the API. Right? Yeah. There's all sorts things, right, where even in GraphQL, you have a special resolver that's like concatenating, you know, the first name and last name to give you the full name. Right? Those types of things In GraphQL, that's not gonna exist in the database, but that's going to exist in the resolvers.

It all comes from GraphQL where we pass it in every single GraphQL will type definition, and it just converts those to it looks for all of the types, makes them into types. It looks for all of your queries, And it links up everything, so it's expecting the right types here and there. It writes your React hooks based on the queries or mutations you need. But, again, those types, The resolver types and everything like that, it all spits it out so that GraphQL acts as, like, the intermediary where it's like, here's your GraphQL types, And those are now the word of law inside of your resolvers and everything like that. Your resolvers are all automatically typed, and your front end code's all automatically typed in. It's pretty pretty neat. Rid. Additionally, you can also pass your we'll talk about your TS config in just a sec, but you can pass your TS config

types that you want to be in your project. And most likely, you're gonna pass that Dom, Node, React, ES 6, things like that. And that will give you all of the FS and all of the node API types and All the vanilla JavaScript types because you're using JavaScript. Yes. But are you using browser APIs? Well, it depends. So you might you have to add those in yourself And whatnot. So it's pretty simple. Generally, you just get, like, a boilerplate

of, TS config, and or you just add those in as you need them. Yep. So I think it'd be a good thing to finish off the episode by talking about just the overall benefits of using TypeScript.

And then we have a lot of rid Niche smaller deep end topics and even, like, syntax y topics that we're gonna get into in further episodes. So if we missed a bunch of stuff, don't worry. TypeScript's a decently huge topic, so we'll be talking about this a lot this year. So benefits breakdown, the big one is really type hinting in your editor. It lets you know what you're expected to be having at every step of the way. It takes so much of the information about how your application expects data rid Out of your brain and puts it into your text editor or into TypeScript so that, you don't have to think about so many things. And to me, that's a huge win because we're already thinking about enough. We have enough decisions to make. To be honest, it seems like this could be a small thing, but the moment that you really get in the flow with TypeScript and it's suggesting everything, you know what When something is potentially undefined, as annoying as that is, it is saving you from headaches down the road. I think this is really just probably rid. The biggest benefit for using TypeScript is that your editor and your build system know how your code should look and function. And for the most part, it's going to catch the bugs. Is it gonna catch every bug? No. It's a giant net, but it's not a giant net that's gonna catch every single little bug. So Yeah. That's a good point. Like, TypeScript rid doesn't run-in the browser. It's only compile time, meaning that any type issues that pop up when your code is running will not be caught. And that's the Sort of the argument for getting types

in regular JavaScript as well, which should be cool. One, like, more thing about that type hinting is that Versus Code actually runs TypeScript on all of your JavaScript as well. And you know when you're you're typing something and you get, like, autocomplete, starts working, you're like, oh, it knew that That property was on my object, and it works. That's because it's, it's trying its best to infer everything based on on ready. Running it with regular JavaScript, that works all the time in TypeScript, which is really cool. And that's just, like, such a major benefit from rid Just from, like, authoring it. Like, you you do take a little bit more time to define all of your functions. And Especially up front, it feels like your every single thing that you do, TypeScript is yelling at you for. But once you get in the flow, once you sorta rid. Understand how it all works. You definitely move a lot faster in your code, which is pretty cool. You move fast and don't break things. Move fast? That's good.

That should be on a, syntax shirt. Yeah. Syntax. Move fast and don't break things. Yeah. I get it.

The next benefit that I rid Absolutely love is the refactoring.

Refactoring is actually built into TypeScript itself. I always thought that this was part of Versus code, but it's actually part of the the Type rid compiler.

So if you wanna rename a variable or a function or a type, all you have to do is just right click rename symbol rid on that value.

And anywhere in your entire project that that value has been used, it will rename it. And this is much better than a find and replace because a find and replace simply just looks for the string of something, and you better hope that you you got it right. Or if you've used that word anywhere else, then it will replace that as well. Re Whereas, if you actually rename symbols, which is could be literally a function name, a return value, a type value, a variable name,

rid It it will do it through it'll ripple it right through your project, which is so cool. It's so cool. I love this. It's one of my favorite. I use that all the time because, re sometimes when you're naming things, you name it something, and it's not quite appropriate. It's it's, like, appropriate in the time or in your brain at the time. And then, like, later on, as The function evolves. You're like, oh, actually, this name would be more appropriate, but I've already used it, like, 8 times, and I don't wanna, like, like, rid Yeah. It's and then that's how your code ends up getting to be smelly because, like, well, you're not you're not picking up after it, and it doesn't make it easy to pick up after it. So Giving you the ability to to quickly change those rename symbols is just fantastic.

I found refactoring overall because, rid. Again, things change. And I'm I'm the type that writes my code and gets it working first and foremost. Like, get your code working, then make it nice. Rid. And TypeScript allows me to get it working and then make it nice with much less effort. Yeah. Me too. I'm just very much, like,

put it all in the same file, rid. Whatever export from here. Sometimes what happens is that if you are importing and exporting something from 2 different rid Files, but they're both pointing at each other. You get a circular dependency.

And in regular JavaScript, it still works. It still works in Node if you have a circular dependency, but it breaks Tools in TypeScript will allow you to just do move that into its own file, and it will update wherever you've imported that thing. Same with dragging and dropping files or renaming paths or renaming file names in Versus Code. Anytime you do that, it will just automatically reupdate wherever you've imported that thing. So it's not like all your imports are gonna break if you rename the thing or move it, which is so, so nice.

So nice.

Nice. What else is so nice,

Don? One of our our 3rd sponsor today, which is a service that Wes and I both used for a long time. It's very fun laughing because if you if somebody were to ask me, like, what I thought about this service, which is Cloudinary. What do you think about Cloudinary, Scott? My answer would be, It's so nice. It it is. It's very nice. I use Cloudinary myself for all of our image hosting. So for those of you who don't know, Cloudinary is the host for your images that is insanely smart. It's not just a a folder you put up and says, okay. Here's my images. Cloudinary does all of these transcodings and modifications to your images to make them as small as possible on the Why? If the image does not exist, it will create 1. You can pass it in variables to the URL to say, hey. Make this image re Sepia tone. Right? We're going in the wild, wild west here. We're doing a photo generator. Let's put the sepia tone on this image. You could do that via the URL, and Cloudinary will just generate that image on the fly. Like, that seems ridiculous, but that kind of thing can really go a long way, especially when you get into new formats because, Like, we've just done an episode last on on Monday on a v or a a v I don't know how to say it out loud.

Rid AVF AVF. These are image formats, and the image formats are coming all the time, and they ship less bandwidth. Rid. And shipping less bandwidth saves you money, saves your users time, and there's really neat stuff in the cloud area where you can say, Give me an auto format for this. As in if the browser can accept WebP, if the browser can accept this or that, rid. Give me the fastest, smallest format for this specific browser as it's asking for it, and you just really can't beat those kind of, speeds that you're gonna get, because otherwise, you just have to assume that, well, I gotta cover for everybody. I gotta cover for all the potential use cases. But with Cloudinary, you could say, hey. Give me that format auto. It's gonna pick the right format for you. And and for the most part, I've had nothing but amazing,

features with this. So I was I was gonna say, format auto and quality auto, name a better pair. Yeah. Name a more iconic duo

Then, those 2 right there. So you're gonna wanna head over to cloudinary.com where you can sign up for an extremely generous free account And get using Cloudinary and just see just really how easy it is to get up and running, drop in some of these images, and really see rid Nice gains in your application in its images. So thank you so much for Cloudinary. Not only a awesome sponsor of ours, but my personal image host. Ready. Yeah. Me too. Right click view

source on any of my websites, and you'll see it's cloudinary in front of that, which is really cool. Yeah. Ready. Last thing we wanna talk about here is just compiling it. We're gonna do an entire show on, like, do you still need Babble? Do you still need Webpack? Like, where does that rid fit into how you're doing it, and we'll we'll cover that in the future. But at the very basic, when you install TypeScript on your computer, You get this thing called TSC, TypeScript Compiler.

And you point it at your code, and it will rip through your code. And it will check that all of your types are there, and rid. It will error out if anything is broken in your actual JavaScript. If it is, it'll tell you the error, and those errors are actually shown in your editor as well real time. Rid. Generally, what what you need to do is you put that as part of your, like, your CI step. So you don't merge code if it's not passing your your TSC.

Rid Out the other end, it will kick out JS files. There's a whole bunch of different ways you can do that. You can kick them off to a common JS modules. Yes. Modules. Just regular JS. So you can pop in a script tag into your browser and then you can go ahead and use that. So rid. It it's not as nice as something like a like a parcel or webpack or or whatnot, but it does do the the main part, which is convert your TypeScript to JavaScript

So you can go ahead and run that JavaScript whether it's a node or in the browser. Yeah. And we actually don't. Rid And the code that we're shipping isn't actually compiled with TSC, but we do use TSC to get that explicit type checking. So what do you use to compile your code then? Currently, we're using ES build, which is a Go based compiler, compiles the TypeScript directly just down to JavaScript, And, the same way that Babble would, just like you can use the TypeScript plug in for Babble. So when TypeScript re 1st came to Babble. Everybody's like, oh, TypeScript's in Babble now, but you don't get that TSC. It doesn't actually do any of your type checking. All it's doing is taking that code And getting it into JavaScript so that it it's basically just stripping out all of the type information

so that way the browser can read the code. That's pretty much all it's doing. Oh, is is that what it does? I always thought under the hood, it was actually using TSC

to compile it all for you, but it's It's not. No. So if you're using Babel plug in Babel for TypeScript or you're using something like ES build, it's important to either run TSC In coordinate in coordinates with, your build time. In fact, we use Snowpack, and Snowpack, by default, will compile all of your TypeScript files using ES build. Right? It just uses ES build. It cranks those down and strips the type out. But if you wanted to, you can install the Snowpack plug in For TypeScript, and all that does is basically run TSC side by side so that when you do have issues, it throws those errors.

Awesome. And one other thing we never mentioned was rid. That React, it supported 1st class, right, in in TypeScript with this dot TSX extension. So you can just write TypeScript rid. TSX files in your TypeScript, which is pretty cool. Yeah. Totally. We'll do a whole show on, like, TypeScript for React because, rid. Man, like, we didn't even get through everything we wanted to today, but there's there's just so much to cover. So in in the coming episodes, we'll have an entire show on tooling, rid Getting past what TSC and TS config are, then we'll get into some more deep end stuff, flow control, error handling, Separate type files, typecasting, async await promises, generics, using JSDoc or TSdoc with TypeScript, which is Using TypeScript without TypeScript,

the difference between interfaces and types, tons, tons, tons to talk about. And it's all good. It's all gravy. Rid Yeah. So cool. So, that was TypeScript. Those grid fundamentals on TypeScript.

Let's get into the part of the show where we talk about our sick picks. Wes, do you have any sick picks for us? Yes.

I'm going to sick pick a label printer for years, probably for, like, 10 or 12 years. When I was in university, I had a rid. Dymo label printer. I I found it at a garage sale. And every time we would go to the bar, we would print this little, rid 2 inch by 1 inch labels and put them all over, like, hello. My name is Wes.

It was so much fun, and I'm starting to try to figure out rid. How we can do T shirts for syntax and and some of my own stuff and whatnot.

And I'm going through the process of understanding all the logistics and whatnot. And Part of doing that is having a label printer so you can you can go really quickly. So I've I had to get a new one because the one I had didn't do the right size. And this one's called a faux memo label printer.

And between this thing and the fact that you can buy rid. 3rd party labels on Amazon, it's so cheap, like, 2¢ per label, and it's super fast. You just hook it right up to your computer. You can automatically print it. So So this is not something that everybody is going to be buying, but if you do need 1, I was gonna go with Daimo again, but they were rid Twice the cost of the one I got, and this one is really, really slick. It works really well. It's it's a thermal printer. So it it doesn't have ink in it. The the paper itself, like rid like a like a receipt that you get out of store. Have you ever have you ever had a receipt and you put it in your pocket, and then you pull it out 6 years later and it's, like, black? Yes. Yes. That's because rid. It got too hot and the thermal went. Or if you ever use a lighter on a receipt, like, you're trying to start a fire, the receipt paper will turn black. That's what thermal printing does is rid. It just applies a little bit of heat to it, and it turns black, so there's no ink. And this thing is awesome. It's called the FOMEMO shipping label printer. Rid. Probably not something everybody's gonna go out and buy, but I am using it to to make, coloring page stickers for my kids

Where you print out, like, a coloring page, and they color it, and then they cut it out, and it's like they made their own sticker, which is cool. That's very cool. Rid Cool. Yeah. I like that. Yeah. Hey. I'm gonna I have a fun little sick pic, and this is going to be I don't know what you what you've done for night lights, rid. But night lights for us have been kind of a pain. We used to have this, like, turtle night light that did, like, sounds, and it could do, like Yeah. You know, light projection on the ceiling. And that thing took, like, 3 double a batteries, and they lasted, like, a week. And every other week, I was getting handed a turtle, Then it was like, dad, please put new batteries in this turtle.

Okay. Yeah. That's going through an outrageous amount of single use batteries or rechargeable batteries for that matter, But it had a a screw so the kids can't get to the batteries. Right? You don't wanna leave a turtle where the kids can get to the batteries in their room, so, like, It had to be screwed shut, which just was like a giant tremendous pain in the butt. So we recently got the kids new night lights, and I'm gonna give Courtney 100% of the credit for these because I certainly did not find them. She found them, and they're these little LED LumaPets.

And this weirdest I don't know if this is, like like, latex or something. It's like the rid Smoothest, softest, thin plastic, material that's, like, squishy. Like, it says it's After the touch, and it is. It feels like a water balloon when you pick it up. Oh, this has the same remote as my LED lights. That's hilarious. Yeah. It's hilarious.

And these things are rechargeable so that you plug them in via USB, recharge them, and you turn it on with the remote, and the light can change the colors. You can have it, rid. You know, on a timer, you can have it switch the colors. You can do whatever. And Landon is old enough where he can have this remote sitting on his bedside.

And if he wants to change his nightlight pink, all he's gotta do is pink push the pink button.

Oh, this is awesome. It's so cute because we'll be reading a book, And then he'll, like, he'll change it to be yellow. It's a little bear. Yeah. It's a cute little bear too. They have a Brooklyn has Oh, they have unicorns, though. Yep. Brooklyn has a bunny. She loves bunnies.

There's elephants. There's all sorts of different ones. They are extremely cute. So, yeah, Lanon will always, like, change it. He'll be, like, Put on yellow when I'm reading a book and be like, dad, it's your favorite color. And I was like, oh, thank you. Thank you. It's very cute. This is good because, like,

rid Caitlin and I just had to go and swap out all of our night lights for LED bulbs because they were all running like old incandescents, and they get hot as heck.

Rid. So this is, like, super safe. It's super safe. They're very cute, and the kids have been absolutely going wild for them. So Big, big hits over here, and and shout out to Courtney for finding that. Yeah. When I picked it up and I squeezed it, it's like this, like, squishy, like, water balloon feeling. You're like, oh, this It's really cool.

Wow. That that's a good one. I like that. I think that we might have to get that for our kids' next birthday. I think that's that's really fun.

Rid Yeah. You're loving it. Oh, man. Shameless plugs. I will shamelessly plug my web development courses. If you wanna become a better JavaScript web developer. Go to westboss.com, w e s b o s, forward slash courses. You'll see a list of all the courses I have on there. Learn a thing or 2. There's a bunch of free ones on there as well, so you can check those out as well. Yeah. Cool. I'm gonna shamelessly plug

level up tutorials .com. Our most recent course at the time of recording this was e s m and snowpack.

And ESM, as we talked about before, ECMAScript modules and Snowpack have just been a huge part of our new tool chain to build rid This crazy fast new version of LevelUp tutorials, which I'm gonna talk about more later.

But if you wanna learn how to use re e s m and get I kid you not, 50 millisecond refresh, hot reloading without losing your react state. Oh my gosh. If you wanna get that in your development flow like we have? Head on over to level up tutorials.comforward/pro.

Sign up for the year where you'll save rid 25%, and you can get access to the ESM and snowpack course, which is really one of my favorite courses that I did this whole year because you really cannot beat 50 millisecond rid Hot reloads on the front end. You can't beat it. It's very cool.

Cool. Well, that's this episode on TypeScript. We will, catch you in the next one. We'll be bringing a bunch more TypeScript episodes this year now that Wes and I are both, TypeScript fiends.

We're types type heads. Type heads. What do you call that? Someone that is A type head is a super into it. Thing that is actually a part of a printing press. Yeah. That would be a good rid Yep. Awesome. Alright. Catch you later. Peace. Peace.

Head on over to syntax.fm for a Full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.

Rid.