Types

[00:00:00]
>> Steve Kinney: Uh, so the one that I'm in right now is this component called name tag. Uh, really all of the action is in this nametag.tsx. And the first thing I kind of want to point out is like, technically, I did have to do a little bit of ignoring like some type checking ESLint stuff. But the kind of major thing that I want to start by pointing out is, other than this file having a .tsx extension, um, there is not a lot going on here, and that will be like, we'll have to do a little bit here, um, but that will be a recurring theme.

[00:00:48]
And even the first few things that I do. Again, you could literally, other than the fact that JSX is also compiled, whatever, um, you could literally change the file extension and everything would be okay, right? Um, and that is again, the beginning of a recurring theme that I want to, like, again, if we structure things well, the amount of actual TypeScript that we need to write, uh, should be relatively low.

[00:01:20]
Um, and so yeah, so this is effectively just a component, but with that, let's, um, let's go and delete this piece. Now, you can see I do have some red squigglies. I have some red squigglies now. Uh, in previous, like iterations of this workshop, we looked at like React prop types and like the previous ways of doing some amount of like type checking on your React component. I feel like in this iteration of the course, in this time period of our lives, I can skip the prop types talk.

[00:01:54]
Um, does anyone, you know, presently use prop types? Exactly. Uh, so the, you know, there's stuff about that. Prop types are a way to basically say, like, I'm going to then put a nametag.proptypes at the end and use this other library that used to be part of React, that's no longer part of React, to say that like name should be a string and is online should be a boolean. Uh, that's, you can just delete that part and we pick up where we are now, and you're already caught up.

[00:02:23]
And that's the kind of the major difference here, which is we do need to figure out a little bit, um, what these things are. And you can see out of the box that if TypeScript cannot and will not be able to figure out what a thing should be, then it will decide that it is any. And we'll look at some TypeScript settings in a little bit. I just kind of felt doing a tour of configuration at the very beginning was too boring even for me.

[00:02:53]
Uh, so we'll get some amount of context, and then we'll go take a look at that. Uh, this technically wouldn't even error, except that we do have strict mode turned on, because if we're going to spend a day talking about TypeScript best practices, having some of the, like, you know, more advanced, more strict settings turned on felt responsible. That said, do I turn all of them on? No, cause some of them are maddening.

[00:03:22]
Uh, so we'll kind of talk about that in a little bit. But the core point is if TypeScript cannot, through any way, shape or form, figure out what something should be by looking and analyzing your code, it will then decide it is any, and any could be anything. Shocker, right? And arguably that gets you no different than you were in JavaScript, right? And so like even if this was a JavaScript component and you were migrating a legacy codebase, one could flip the, you know, turn strict mode off for a hot minute, flip the J to a T, and still be in business, right?

[00:04:01]
But what I want to show you is, for starters, the fact that we can get all those red squiggly lines to go away without writing a single line of Java or TypeScript, right? Uh, and here's how we do it. And this is a kind of a fundamental like philosophical principle, even though it's super simple, that we will kind of hammer on, which is if I even said that name by default is an empty string, my red squiggly went away.

[00:04:31]
I could even say that title by default is an empty string, that level is by default 0, and that is online by default is false. And I can save that file, and you'll notice, not only did all my red squigglies go away, despite strict mode being turned on, that this is still valid, at least JSX, right? Um, you know, if, if one turned these, uh, HTML looking tags back into their like representation, this would be valid JavaScript that we could even paste into the browser like console and see.

[00:05:06]
Like, we can't because it's JSX, but like TypeScript not the culprit. They are JSX is. Um, and so we can see is that if we have given TypeScript any way to even allude to the hint of what this might be, it then does the rest. So if like we feel like our TypeScript in our current app is really noisy and all those things, and it feels like a chore, right, there is a path towards, and this will be a thing that we'll see and build on top of, you know, with hooks, and with reducers, and with API calls, so on and so forth, um, to kind of try to keep this alive as much as possible.

[00:05:46]
Will we have to write TypeScript at some point? Of course we will. Uh, but the goal is again, to kind of mostly get all the benefits whilst also keeping it out of the way. Uh, so in this case, we do, we have, we have effectively, uh, the type safety in this component. You can see that if I were to, um, try to insinuate that, let's say, uh, let's make title equals 42, right? It is going to give me the red squiggly of doom saying, hey, this is a string.

[00:06:29]
So the type checker is alive and well, right, and we are able to kind of get that benefit for free. Now, if I was to remove the hint, uh, in this case, it's any, and any is just basically JavaScript, any is any, and any is going to be our worst enemy, and we will seek in all cases to eliminate any, because once something is anything, it, everything it touches gets infected by its anyness. Not a real term, but we'll use it.

[00:07:02]
Uh, so we want to try to avoid that at all costs, hence the strict mode being on, because the easiest way to get any infect in your codebase is to do it by accident, right? When we look at some configuration stuff between TypeScript strict mode and a little bit of help from our friend ESLint, right. We can both turn off no implicit any, and then also turn off explicit any, which should be the Venn diagram of all instances of any.

[00:07:32]
I say that, that's not totally true. And I will tell you the, I will tell you the nuances of that later, but let's just pretend that I'm right at this point. Cool. So that's the starting point, but like this is some problems. There's some problems here, which is cool. I gave it a bunch of default values, and it was able to use those default values to infer what the types are, but that is effectively a little bit of a behavior change.

[00:08:03]
Now, if I wanted to say that name is absolutely a mandatory, um, property, that's not going to be the case because there's a default, right? If I hover over name tag, you get a sense of what the type of this component is already, right? And so it says name, we see a question mark, it's either string, or because we have a default there, it's undefined, right, they, you could have it as undefined and then that empty string would be the default value.

[00:08:27]
Not what we want. What we want is to say that name is a required property, title is a required property. And if you want those other two to be optional, then this works and you don't even have to put a type on it. Um, but we want, we kind of want to get all the way there. The other important part, because again, I said, most of how we're going to do this today is like just hovering over stuff in our editor and realize that all of the answers are readily in front of us, either by hovering, by hitting the tab key at some point or something along those lines.

[00:09:05]
We get most of the hints. So in this case, it is a functional React component. And you're like, what is the type of a React component? Well, one can hover over the name tag, uh, variable and see that this is a function that takes this object, right? And it returns a JSX.Element. That is the return type of a functional component in React, and we didn't have to look anything up, right? So if we ever needed that for some reason, and it's there's some nuances, you won't, um, but if we did, and for other stuff we will, then hovering over stuff is usually the answer versus like, I'm going to memorize everything.

[00:09:50]
I mean, go for it. But, uh, hovering over stuff also super effective. Okay, so if the challenge now is to not, um, have like these default values, we do need to at least give TypeScript a little bit of a hint on what these things should be, right, and you kind of almost can see what this index might be from the said hovering. The, you don't have to do this, but like, honestly, the, I would say the convention that you will always see for this is doing something like type NameTagProps, which at least is incredibly descriptive of, uh, what this type is.

[00:10:26]
It's the props for the name tag component. You're like, I don't want to name it that. Okay, don't name it that. Um, but that is the, that is the canonical thing you will see, but you can name this anything that you want. Uh, and here we kind of just once again define that, we just give TypeScript those hints in this case, we could say the name should definitely be a string. We could say the title should definitely be a string, we say level should definitely be a number, and is online should be a boolean.

[00:11:12]
If one wanted to make any of these optional, right, you could simply put a question mark here, and now they can either include it or not include it. Um, either way, we're good, right? And we can then get rid of these default values. We'll see some red squigglies for a hot minute. Turn all those off, and really what we need to do is then just give TypeScript the slightest hint what type this object should be, right?

[00:11:45]
And that is simply NameTagProps. And if you look, now, we can see that this is an object that takes, or a function that takes an object that has a name, title, level and is online, which JSX is going to do the attributes for that. And that is defined here, and it, we don't actually have to, uh, say what the return type is. If TypeScript, again, this is a recurring theme, if TypeScript can figure out on its own what the return type is, you don't have to say anything, right?

[00:12:21]
So if you hover that over again, you can see, it takes these things, it knows that that's NameTagProps now because we did give it that hint, because before it was used in default values, it returns the JSX.Element. Could you do this? Right, uh, I think I got him for that. Um, yes, right, that is effectively the same thing. Uh, the, uh, it's definitely a tradeoff. Like, the nice part about being declarative of what you want the return type to be is if you are wrong, it will give you an error, because like if it is doing the thing of it is trying to infer what the return type of this function is, it's going to look at the code, and it's going to then try to at least guess what the return type is, right?

[00:13:13]
Um, but if you say like, hey, and by the way, this JSX or this, uh, React component should definitely return a JSX.Element, if for some reason one made a boo boo and like forgot the return, you will get that visual notification, right? Or if you kind of had some kind of conditional, like, if true, return null, or even like, probably something like here I get one at the return value, um, as well, it's like I got an L going like what are you doing if true.

[00:13:49]
Um, but we could say even if Math.random or whatever, right, we can see that like, hey, you can't return no, cause you said that this returns a JSX.Element. If one got rid of this, uh, then theoretically this is valid, and nametag is like, I either return a JSX.Element or null, right? Because again, it looked at the code, it said like, well, this function either returns JSX.Element or null, thereby, um, that is what we have.

[00:00:00]
And like, you can argue, well, that's bad, right? Like, but like, uh, no it's actually a real legit value in this case, but like theoretically, if you return some real, uh, garbage or whatever, then it would break somewhere else.