Literal Types

[00:00:00]
>> Anjana Vakil: Did anybody keep an eye on these tests running Because they seem still not to be happy I'm just going to show that I ran this command with npm run tests and we're still not done because we've got some unexpected results We're still getting an undefined somewhere, and we're still getting a value that we didn't want here In this header test, we're getting a lite with an ITE instead of light with an IGHT

[00:00:41]
So let's see what's going on in this header Did anybody notice this bug in the app when we were playing around with it I mean, okay, this is a really simple app, but it has the one thing that all websites must have: dark mode So let's, oh, I'm just refreshing this Okay, there's up here, there's a little like button It says toggle color scheme

[00:01:11]
If I press it, it goes to dark mode If I press it again, it goes back to light mode Isn't that great And then if I press it again, it, wait a minute, does nothing because misspellings So what we have here is there's like a data theme attribute and essentially we have a confusion about how this value is supposed to be spelled Is it light with an ITE or light with an L-I-G-H-T

[00:01:45]
And that's where it can be really helpful to use those literal types that we talked about earlier If I say like, make a type called theme, and I want to say this isn't just going to be any old string like LITE There are exactly two values that I want this string to be able to have One is dark and the other is light So if we now, this is a use case where we get these literal types where we want to say, hey, this theme literally should only have one of these two values

[00:02:29]
Do not allow anything else And so if we then use this theme to say like, maybe we have a current theme It doesn't like that because we're getting this attribute and like the document might not have that attribute anywhere on it So that's actually helpful We want to make sure that we're handling that null case However, we could say declare a new theme, for example, and say that that is going to be one of those two theme values

[00:03:03]
And then we could say within our if block, like if current theme is dark, make the new theme light And if current theme is light, make the new theme dark And then we can refactor this to set the attribute to be the new theme, for example Used before being assigned Ah yes, okay, sorry, I meant to do that up here And here, okay, so now in the case where I had misspelled this light, TypeScript knows that that's wrong and we should not allow it in our code

[00:04:05]
So this is another case of how like TypeScript by default has no concept of what I'm trying to do in my codebase It doesn't know that I'm trying to like build a dark theme, light theme switcher It doesn't know what values I might be passing around as attributes of my HTML elements, but I can tell it And the more specific I am, the more narrow my types are, the more stringent I make TypeScript be with me, the more help I get out of it

[00:04:41]
And so writing my code, refactoring it as we just did in a way that allows me to make better usage of type information than the way that I had written it before, is something that we need to spend some effort and some energy and some mental power doing as we're refactoring or migrating a codebase to TypeScript But it can pay off because it can do things like catch wrong values that our loosey-goosey JavaScript code would never have complained about

[00:05:18]
It would have just not done anything when I clicked the button, which is exactly what was happening So now we can make sure it's spelled correctly We can see the tests pass and if all goes well, we can switch the color as much as we want Okay, a very simple example, but y'all, we did it We banged our heads against the table Uh oh, wait, what's still passing

[00:05:56]
Okay, we've got an optional field We probably need to put a question mark somewhere on one of our types, but we know how to do that Yeah, so we said we expect the result not to contain undefined, and somewhere we have an undefined, and this has got to be in our events test So something somewhere here, we are getting an undefined value that we didn't expect

[00:06:22]
So it's where we're giving information about the host, which, oh, we have there So here we have an optional description property, and the way that this is written, we're trying to guard against the case that it's undefined But because we're using this operator here, our double ampersand, this whole thing, if description is undefined, this whole thing is going to evaluate to undefined

[00:07:09]
And then because we're putting it in a string template, and here we've got kind of like a template within a template, that's going to put the word undefined in our string And so here is an example where TypeScript can help us a lot, but it can't help us with everything And for example, it knows that an undefined might be here, but it doesn't know that we don't want to render that undefined in our string

[00:07:49]
So we probably want to write this a different way Like, for example, we could do something like have a description string or something like that equals e.description, or if not, then it's the empty string, or sorry, I could do e.description or empty string, for example, and then we could insert that here Or we could do the ternary if thing in here and say like, oh, if e.description, then do that, and if not, then give me an empty string

[00:08:34]
And the, sorry, this is an alternative way to do description string Now let's see Haha, now we're no longer getting undefined in a string And the thing is that this is what I'm trying to illustrate here, is that TypeScript will not solve all of our JavaScript problems for us We still need to know that we're working with JavaScript, and JavaScript's fine with undefined going into a string template

[00:08:56]
And what it's going to do is it's going to call undefined.toString, and that's going to give me the string undefined, and then that's what's going to go in my page And so this is why, in addition to having the type checker make sure statically before we run any code, so at development time or at compile time before the code ever runs, we want the type checker to do as much work for us as possible

[00:09:28]
However, our test suite is actually running our code and is actually seeing what it outputs And so TypeScript does not replace the programmer's brain or a good suite of tests Not that this is a good suite of tests, but it doesn't do everything for us It sure does a lot though So what I'm trying to get across here is we can't completely turn over all of our thought processes to TypeScript and let it just tell us whether or not our code works because it doesn't know if our code works

[00:10:05]
It knows whether looking at our code, everything looks like it ought to check out But TypeScript has no idea that we have a problem with the string undefined showing up for our users And we have to tell it that in, for example, test suites or integration tests or whatever we're doing We need to still use our brains and use our programming chops to make sure that our code is behaving as intended at runtime, in addition to that it all looks good and has the right flow of data types through it at compile time or at writing time if we think of it like that, at development time

[00:10:54]
Okay, that was the only point of that very pesky error But now, now we have green across the board and hopefully that makes us feel a little bit of dopamine in our brains.