Transcript from the "Variables" Lesson
[00:00:19] We'll talk a little bit about objects and then the equivalent of the logical AND and OR operator end types. So we call these union and intersection types, but they will remind you a lot of AND, and OR. So we're gonna switch away from this slide here. But if you wanna follow along, there are a bunch of files in the notes folder of the exercises of this workshop project.
[00:00:47] And I've done this deliberately so that you can hover over things, and look at what the tooltip say, and kind of poke around at it. So like feel free to do that as we're discussing, because your editor is gonna give you a lot of feedback about what's going on.
[00:01:03] And I'm gonna walk through and uncomment things step by step so that we can kind of learn about how TypeScript works incrementally.
[00:01:38] Like I declare that x exists. It's a let declaration. Anybody know what makes this different from a const declaration? What's the difference between let and const?
>> Speaker 2: Reassignment.
>> Mike North: Reassignment, so let can be reassigned, const cannot. The type of x ends up being string. That's what our tooltip tells us.
[00:01:59] And that makes sense because we're initializing it with a string. You don't really have to do too much work to understand that. What we're seeing here is inference. We don't have to type absolutely everything in our app. In fact it would be a bad idea to do so.
[00:02:13] You kind of end up typing yourself into a corner, you make your program very, very rigid if you type every single thing. So just like any let declaration, we're able to reassign it without running into any trouble, x = "hello mars". The new thing that TypeScript is throwing at us is we get an error here if we attempt to assign it to a value that's not of the correct type.
[00:02:45] And the error we're getting is, 42 is not assignable to type string. This is obviously telling us that there's a mismatch of some sort. And we'll explain why this 42 is here instead of a number in just a moment.
>> Mike North: Or instead of the word number. So let's look at the same example but with a const declaration.
[00:03:14] The type is different here. The type of y is literally the string hello world. And the reason for this, the reason that we can make this type so much more specific, and it's specific because this variable cannot hold any arbitrary string. If we think of types as sets, right, it's like buckets of allowed values.
[00:03:41] Our let declaration, that variable could hold any string. This can hold specifically a string whose value is hello world, and no other string. If we tried to change it down here and set it to, well if we tried to reassign it, we'd run into a problem in general, because it's a const.
[00:04:03] But if we tried to pass it into a function that wants hello mars,
>> Mike North: We'd run into a problem here saying "hello world" and "hello mars" are not compatible, right? So this is what we would call a literal type. And that means you're enumerating a set of allowed values, specific string, specific numbers, something like that.
[00:04:37] And you really could only pick from one of that set of options. Now this is TypeScript being specific because it can. And it makes us kind of wanna revisit the let here. So if the let declaration were to take on a value. If that variable were to take on a value of whatever string we initialized it with up here, we would have run into trouble in reassignment, right?
[00:05:02] If it were instead of calling itself string, if it were to say hello world, now it's like set itself up to be way too specific by default. So this is one place where TypeScript is trying to be as useful and strict as it can without getting in your way.
[00:05:21] When you're dealing with a value that's not reassignable, and the value itself is immutable, we can't change this string, we can't re-assign the variable, it's set in stone, we can be maximally specific there. We'll see this come up a couple of times as we explore different things. Yes?
>> Speaker 2: I have two questions, one of them is simpler. So when the tool tip shows up with the comment, is that a feature of native TypeScript or is it a feature of TypeScript's compatibility with JSDoc?
>> Mike North: When we see the comment pop up?
>> Speaker 2: Yeah, yeah.
>> Mike North: So you're asking about this down here, good question.
[00:05:58] So you said, is it a feature of native TypeScript or a feature of JSDoc and the editor, right? Kind of both, TypeScript can understand those comments and language server is actually pushing that comment data up to us. So the end of the when we start playing with TypeScript compiler API, we're gonna build a quick and dirty documentation tool.
[00:06:25] And you'll see that in addition to parsing the executable code the inert comments, come a long with it and we can actually even grab JSDoc tags. So comments are entirely inert in TypeScript. There are certain things you can do that will affect the output, one example would be if we did @internal, this is recently added.
>> Speaker 2: Cool, and then the other thing I was going to ask was, so for declaring with const, and it's like an object, with keys defined obviously like, you're getting there.
>> Mike North: Great question, sorry to cut you off there, I just know exactly where you're going, so let's try this a different way.
[00:07:37] Const yObj =,
>> Mike North: So same deal, right? We have const declaration whose value is an object. It's going to take on the type, just as it did. Now, note that the value of, sorry, the type of foo within the object ends up being a string, why, because the object is mutable.
[00:08:04] Consts can't be reassigned, and that means we can expect the property names in this object to, we'll want them to remain what they are. The assumption is you set this up deliberately with the properties you wanted there and if you wanted to add additional properties, you would have to give TypeScript the clue about that.