Transcript from the "Arrays & Tuples" Lesson
[00:00:00]
>> Let's talk about arrays. So we've talked a little bit about object types. Obviously, arrays are the other main type of collection that we work with in JavaScript. And sort of key value storage we have positional storage. So, typically, for at least simple types of arrays, all we have to do is add a pair of square brackets after the type of the member of the array.
[00:00:27] So this would be an array of strings. And you see the inference works here, just as we would hope where we don't have to explicitly write a type annotation. TypeScript understands what's going on. We could use our object type here as well to say we have an array of cars and we could start with one car in there.
[00:00:47] So this you can think of it as like this is just as much a type, as the word string is a type and it can be used in all the same places. So that's simple arrays. Let's talk about tuples. So tuples are, I mean, you could have used tuples in regular JavaScript if you wanted to.
[00:01:09] There's no special treatment. It's more like just a pattern. Where you have some meaning of positional ordering of different pieces of data. So if we wanted to store our 2002, Toyota Corolla, we could just have a convention that says, the first member the first element of the tuple is the year followed by the make, followed by the model.
[00:01:37] So we could store it like this. And then this makes destructured assignment really nice because we can then pull out the individual little parts of this compound value. And do something interesting with your making model. So, unfortunately, inference is not going to be our friend here. And again, we're back to the theme of TypeScript making.
[00:02:04] We're trying to make a reasonable and safe assumption, that will stay out of our way most of the time. And in this case, it's decided that what we're trying to do is create a mixed array of arbitrary length that contains some mix of strings and numbers. And that's gonna be a problem for us, why?
[00:02:30] Well we could add an additional element, right? Like this is a sedan versus a coupe. The year is not in the right place, right? The year should be the first element and this is in the second position here. So it's just not describing things as tightly as we really want.
[00:02:51] I invite you to think about this question. What do you want most of the time? So sometimes we return an array that has two things in it and it's always two things and there's always a number and then a string. And other times we use arrays of arbitrary length.
[00:03:07] So show of hands, who uses arrays as like arbitrary length collections more often than like, just a pair of things? Like I know I do. And in the chat, you can just type y or n, yes or no. Yeah, I see some hands up. So TypeScript is designing around this.
[00:03:28] They don't want to mess with your regular array use case. And this is not a big problem, but all it means is that you're going to have to explicitly state when you intend for an array to be treated as a tuple. And you're gonna just need to define a type annotation in that case.
[00:03:46] Again, it's running with the theme of type strip trying to stay out of your way while providing you with safety. And here is what that tuple might look like. So within the square brackets, we're simply indicating with each position what type of value we expect to find there.
[00:04:10] In this case, we're being shown that or being alerted to the fact that two things seem to be out of place, TypeScripts, not happy with the first or the second element here. And that's because they need to be switched in terms of position and then here we're seeing that source has 4 elements, the target only allows 3.
[00:04:30] It's basically saying the right hand side has 4 things on the left hand side, you have my car and you told me I should have 3 things. Therefore I object, right? So this is how you define tuples. They're, really useful in cases where you want to return multiple things.
[00:04:50] But maybe it's not a type that's so formalized that you wanna store things under property keys, like often, maybe for form validation case, right? I don't want to throw errors. I kind of want to return errors. I'll return a tuple that has in the first position, a string that's like success or okay.
[00:05:10] And then data, or the first position it'll be like error and then followed by the error. But this is a pattern you see often in languages like Python or Elixir. Where you return these things? So, you do want to be careful here and TypeScript 4.3 it's the latest release.
[00:05:38] So I'm leaving this immortalizing this comment saying that, something might happen in the future, but today there are limitations. There is not a whole lot of support for stopping you from treating this like an array. So in this case, you can see that during assignment, we get the error messages we would hope to get.
[00:06:04] But in this case, you can see that we start with a two element tuple. We can push the third one in, we can pop them all out and TypeScript is not going to stop us from doing anything here. I can give you a hypothesis as to why TypeScript letting us do this.
[00:06:22] And it's because there is no type equivalence check on num pair that happens when we invoke methods on it. There's no concept in TypeScript yet of like, I'm calling this thing push. Therefore, the thing that I was invoking it on, like numb pair, it's type should change. There's no concept like that in the language yet.
[00:06:49] So you have to be aware that you only get that validation on assignment and you can still shoot yourself in the foot by messing with your tuple using push and pop. And Luis points out there's a proposal for real records and tuples and JS. That's, great. There are a lot of proposals for things in JS.
[00:07:16] So I wouldn't wanna represent that this is coming or even likely, until these proposals advance to like at least stage three. Seems like the kind of thing that might work though cuz it's to be reasonably performant. All right, and Niche has a question that I need to read for a moment.
[00:07:38] Okay, I'm just gonna sort of boil that question down and Niche asks a question about is the JavaScript community, and really it's like TC 39, the committee that decides what JavaScript is. Are they going to make JavaScript a statically typed language? I think it's extremely unlikely. I'm gonna say less than 1% chance, probably much less.
[00:08:08] And the reason is, this works pretty well, having sort of JavaScript be a compiled target. Now, what's more likely to happen is something around WebAssembly where you have other typed languages that compile out to WebAssembly bundle. And maybe that includes some runtime type checking. But remember this runtime type checking does not come for free.
[00:08:37] And we still have a lot of JavaScript to run in the world. So I do not expect types to be added to JavaScript directly. But that shouldn't get in your way because you can use this and treat JavaScript as a build target.