Transcript from the "Index Signatures & Object Q&A" Lesson
[00:00:00]
>> So great, we learn how to type rigid objects. What about dictionaries? So let's imagine an address book situation. I know the address book and my phone lets me store multiple phone numbers where I could say, home, work, fax, pager, whatever apparently grew up during the 80s. So might look something like this, right, where we have a consistent type of value that is stored under an arbitrary key.
[00:00:31] So we have this nice way to easily look up values by key, just give me the work number. In order to type this properly, we need something called an index signature. And here's what that looks like. We have these square brackets and you should think of this almost like box notation for accessing a value off of a property, like dictionary square bracket and then a string for the property key.
[00:00:57] That's a good mnemonic device here, right? So you can pass in any string, you can call this k whatever you want. It's sort of arbitrary, cuz you're not really consuming k elsewhere. And then this is the type of value that you will find under each key. And here we're starting out with an empty dictionary but you can see we can reach in and we will get this object out.
[00:01:20] Now, I'm showing you this flavor of a dictionary for simplicity. What I like to do is add, and I'll go out to the playground here. I like to do this because it's bothersome that we know this is empty, and yet we're reaching in and assuming facts will be there.
[00:01:42] Do I really wanna be able to do this? Which this will happily let me do. I kinda want that extra rigor of being asked to check whether fax is actually present or not. But it's up to you different patterns work for different use cases. You pass a variable with extra property to a function that does not use that property and it'll be okay.
[00:02:12] It does sound like you're describing the excess property erroring case. TypeScript is basically trying to discourage you from adding extra stuff to object literals which it can guarantee you will not be able to safely access from within the body of the function. And Theresa asks, why does storing that object as a variable get rid of the error?
[00:02:45] Let me take us back to that little screen. So why is it that if we take this here, cut my car. So, when we weren't using this through a variable we went in here and we said, well, let me just copy this. So we've got a variable right now we're not currently using and we're passing this in, we get this error message.
[00:03:22] So I suggest that there is no way to safely access color. No way, within the print car function. Like first nobody can see this object other than print car. It's an argument that you're passing to the function, out here there's just no way for me to access that object that I've created, to pass into the function.
[00:03:49] The only place we can access it, is from within print car. And within print car, we've stated that, this is the type of object we receive. So, if I do car.c colors not appearing on this list. We can't access that color property. So based on the fact that only print car can see it, can see the object, and print car won't be able to access that color property that's why you're getting that error.
[00:04:18] Let's see if those same conditions hold true in the case where we're using the variable. So I'm gonna replace this with my car. And print car still cannot access a color property because it doesn't state upfront that color might be there. However, down here, We can see color, right?
[00:04:48] We have this variable and conceivably we could use this variable in other places, in other ways, maybe for a different function that wants to see a color there. So, in the case where we're storing this as a variable, you cannot prove that the color property is a waste.
[00:05:10] You cannot prove that it's pointless and that's why we no longer get the error. You only get the error when it can be proven that the property is pointless.