Transcript from the "Typing Functions Q&A and Objects" Lesson
>> Why does TypeScript not complain in that example, where I'm passing a number into the promise constructor whether the result is any? Yeah, it's kinda mysterious, right? So I'm gonna go back to that example because it is quite shocking, right? Let me let me take us back here.
[00:00:20] It's this one right here. Like the reason I show this to you is because n E's are dangerous. And the fact that in this case, just to recall, like what stage of the code we were at here, we had not given arguments a type and therefore, like what is a plus b even mean when a or b theoretically could be anything right?
[00:00:44] We don't know. So result ends up being in any. Now, the point here is that an any does not just cause problems that have to do with itself. When an enemy is passed into well that flexibility will compromise that well typed code. So in this case, an any variable can hold anything, and they can also masquerade as anything.
[00:01:18] That's a useful way to think about this. It's a wild card It can accept anything, but it can also present itself as anything. And in this case, that's gonna cause problems, even if your types are really, really good about where that any goes where it enters into. So that's the liability of having something like this.
[00:01:45] Hopefully that makes sense. It can masquerade as anything. Louise making a comment about my unit test remarks. Yes I agree with you that, the guarantees and the checking that type script gives you in a, in a declarative way, right? These constraints, they help avoid defensive programming to some extent, but when we start building type cards, you may accuse me of defensive programming again.
[00:02:11] So I wish to withhold your judgment for the time being. All right and he says much of the job of TypeScript is about type annotation. The JS doc introduced way before TypeScript was inter invented. Let me rephrase this question. So, Annice you're basically asking, like, why do we say that there's so much value that comes along with TypeScript.
[00:02:36] When you could have done some of these things in the JS doc world. That's a very fair point. But let me show you this. Let me show you what you could have done in the JS doc world. So Annice is referring to the fact that I could have done.
[00:02:57] Sorry I always forget the ordering of this. Let's hover over these tool tips. Oops maybe I'm doing this wrong. I think it's like that. Let me try one of each, see if it works. I think the fact that it's running in the type playground is hurting us a little bit here, But take it from me, I really think it's this B and A number.
[00:03:34] So you could have done something like this. And if this were a more normal environment, we would have seen that like a and b are regarded as numbers. But here's something that JS doc would have also let you do something like that right where you forget to add a type for one of your variables and defining more complicated types in JS Doc is really complicated, things with type params and stuff like that.
[00:04:00] So really what JSDoc was missing was strong enforcement of alignment. Between the comments that you're writing and the code that they were documenting that that was hard, and for that matter within your function, JS doc was probably not helping you much unless you're being extremely vigilant about saying like result equal saying Something like this.
[00:04:33] This level of JS doc might have gotten you a long way, but I don't come across too many code bases to do this. It's a lot of vigilance required to keep all this up today. Okay, I am actually gonna proceed because a lot of these other questions I know we're going to get to later on.
[00:05:06] Nita asks what is a use case for any. We're gonna talk about that in the section called Top and Bottom tyes, dedicated discussion around any and it's kind of a part of network and unknown which is kind of like a special program. So with that let's pick back up.
[00:05:50] So when we talk about the types of objects, they are two things, what properties are on this object? And what are the types of these properties? And that applied recursively could describe deeply nested objects, or very small objects. I mean that that's the core principle. Some people refer to this as a shape, right?
[00:06:15] What properties do you have and what kinds of things can I store under each of the properties? So let's just start with a conceptual model of a car, which we could describe as like a 2002 Toyota Corolla. It has a year a make and a model, the make and the model are going to end up being strings.
[00:07:01] But instead of key value, we have key type. We can actually use this colon type syntax with this structure that we've created. If we hover over a car, we can see that it's stuck, right? So just as before where we were saying, age colon number, or end time colon date, we're seeing car colon and then this big thing that we've created and that's a type of object.
[00:07:35] If we wanted to use this to describe an argument, we can do this. And we can see that as we reach into this object and we do car.make, make as a string, model is a string, and year is a number. So this is where we're getting that nice validation and these would show up in autocomplete as well.
[00:07:57] If you did car.m, you would see that making model drop down.