Transcript from the "Array Destructuring" Lesson
>> Kyle Simpson: Let's set this up real simply, lets imagine we have a function called foo that returns us something and I'm gonna start easy, I'm gonna start with an array. Let's say it returns us an array like [1, 2, 3]. And then we wanna consume that value, in some other part of our program.
[00:00:19] So we're gonna to call foo and what we're gonna get back is an array which is great, we can say var array and get back that array. But what if, in that part of our code we need to individually reference different values? We don't wanna say, arr of 0, arr of 1, what if we want lexical names to reference in like for example a, b and c.
[00:00:41] So, what you might be in the habit of doing, is something like assigning this the tmp variable and then creating individual assignments.
>> Kyle Simpson: Whether you knew it or not, this practice has a sort of general category name in that practice is destructuring. And that term, that idea of manually destructuring, the way to think about what that means is to take a structure llike an object or an array, and to deconstruct it down into its constituent parts through assignment.
[00:01:21] So really, destructuring is an assignment operation. It's taking some bigger thing and assigning off its individual parts, into different variables. We can do so manually. But this of course, is the imperative version. And it's not too complicated right now, because there's only three of them. But we can start to throw more and more bits into the process and very quickly, that imperative code is gonna get super complicated to read through and understand.
[00:02:30] I'll put on the other side we're gonna take the foo value, the return value from the foo call, and we're gonna destructure it. The way we're gonna destructure it is, we're gonna declare over here something that looks like an array but it's not an array. And that array looking thing that's not actually an array, is going to say where we'd like stuff to be assigned.
[00:02:55] It's basically gonna list out a set of targets for those assignments. So we could say something like a, b, and c. So, it looks like an array on the left hand side of an assignment. If it were an array, this would be a nonsense statement because there's no such thing as having an array being the source of an assignment.
[00:03:15] And array is a value. It is the I'm sorry, there's no such thing as making array the target of an assignment. It is always the source of an assignment, because it's a value. Butt this isn't an array what this is, is a pattern. There is an analog that's similar not the same but similar in other programming languages that you may have heard of before, called pattern matching.
>> Kyle Simpson: Are you following me?
>> Kyle Simpson: Now, it won't be obvious yet why. But it will as we go along. That I'm gonna say. As soon as you have more than like two or three of these, you're not gonna wanna put these all on one line. Just like it's not a good idea to try to put your arrow functions all on one line just cuz, so you look elite.
[00:05:19] And they're one of the best tools that we can use for readability. So I'm gonna say, stop that habit of yours of trying to look for every possible way to get stuff up onto another line. Use new lines, and white space, and indentation liberally. Because it's one of the best ways that you can make your code more effective at communication.
[00:05:41] Look for the opportunities that you have, to format your code in such a way that it will be more readable. So what I've just done is break, broken those out onto another line as opposed to putting them all in one line. Won't be terribly obvious yet why I did that but you'll see in just a moment, why I really think you're going to want to get in the habit of putting your destructuring patterns broken out across multiple lines.
>> Speaker 2: Breaking it out across multiple lines also has that side effect if you use something like git. Of making your difs more clear-
>> Kyle Simpson: True.
>> Speaker 2: When I've added one value, so.
>> Kyle Simpson: Very true. That's not really anything about destructuring, but you're absolutely true. If you break things on to multiple lines, and git obviously makes its differences in a line based sort of way.
[00:06:26] So, it's a lot easier when you have multiple lines, to know where the differences are. Of course, now we have the problem of coma first or coma last with gits or whatever, but that's a separate issue. And by the way, you can do trailing comas. So, you can get a little away from the get problems if you want to.
[00:06:49] So what we said here is go break this thing down and assign these things. Now what would happen if the array that we a that we got back actually had fewer values. But just think about it from a processing perspective what would happen is exactly what you would expect, which is it would try to go to the array value.
[00:07:08] And it would look for an item in position two, because we said we're expecting an item in position two, what would it get back if it said array of two? It would get back undefined. Because that's not a present value in our array. So c is still gonna work, the assignment is just going to be that c's starts out as undefined.
[00:07:31] So, it's totally okay for our pattern to account for more values than we actually get. It's also okay to get back more values than we account for. If we only account for these three, the value 4 that comes back. That gets silently thrown away. No big deal.
>> Kyle Simpson: So this pattern does not have to be a fully inclusive pattern, it can be a partial pattern for the stuff that we care about.
[00:08:01] That's the point I'm trying to make. Yes.
>> Speaker 2: Can you have default values in that?
>> Kyle Simpson: We're getting there. We're getting there, okay?
>> Kyle Simpson: This pattern says I'm expecting something kind of in this shape. Let me give you a scenario, and it's not gonna look obvious yet. But let me give you a scenario, where I really think this starts to shine.
[00:08:26] You call a function or get some value back from say an API call to some JSON API. And you get back some big complex object of arrays, of objects and all that other stuff. And you wanna reference things, three or four levels deep down inside of this one part of this big object that you know you're getting back.
[00:08:45] You wanna reference those with lexical variables. What do you do, you end up doing some really complicated version of what we have on the left where it says, tmp of 0.a of 3.foo.bar.baz of 1 and going really, really deep and all this crazy nesting into it. And now your code is super imperative and super confusing.
[00:09:07] Or, you can declare a nice clean pattern that says, this is the shape of stuff I'm expecting to get back and if I get something that matches the shape I want you to make these assignments. That's the difference between declarative an imperative here.