Data Structure without Iterators

[00:00:00]
>> Kyle Simpson: So the sounds real great that we now have this iterator protocol built in and we should be able to use this with all of our favorite data structures. Except there is a problem, which is what do we do about data structures that don't have iterators. It turns out that not all data structures have iterators.

[00:00:23]
The object is a great example, object does not have a built in iterator. So if I make a regular plain old object and I call for of on it, I'm gonna end up getting a type error. It's a type error because the for of loop tries to access the symbol.iterator location on that obj object, and it doesn't find anything defined there.

[00:00:48]
So when it tries to execute, it's trying to execute the undefined value.
>> Kyle Simpson: It's kind of frustrating that of all the data structures that are built into the language, the one that they didn't make automatically iterable is the one that most of use. Which is we make our own JavaScript objects.

[00:01:08]
There's a variety of historical reasons for why they didn't ship a default iterator on it. But the bottom line is that it is not actually that difficult to define our own iterator. And that's why we're talking about this is, is we wanna make our own data structures, and we wanna make our data structures adhere to the iterator protocol.

[00:01:28]
So if we know that the for of loop or the dot dot dot operator, the way that it works is it automatically tries to find something at that position, symbol.iterator, then all we need to do is define one at that location. And then the for of loop and the dot dot dot we'll use it.

[00:01:46]
So let's try first to create our own iterator factory function. I call it a factory function because every time you call it you would produce a new instance of your iterator. You can iterate something multiple, multiple times if you want to. So here it's a function, and on line 6, for example, you'll notice here that basically I'm just getting the list of keys for my object, which would be A, B, and C.

[00:02:16]
And then I am returning back an object. And my object has one property on it called next, that's what interators have, is they have a next on them. And when I call that next method, you'll notice that the next method does one thing, which is check to see if there's anymore to iterate over.

[00:02:35]
And if so, it returns an iterator result that is done false, and then it has the value. Otherwise it returns an iterator results with done true, and value undefined. Exactly the same way as all the built in iterators do, they return of two kinds of iterators results. So I'm simply returning the results until I've gone through all the keys.

[00:03:00]
That now has the effect down on line 17, of actually, if you look down here on line 17, it has the effect of pulling out the values from that object into an array one, two and three. Same if I had done a for of loop, I would have been getting the values one, two and three out, okay?

[00:03:20]
So, some of you may have noticed that I use an arrow function. And if you followed me much, you know that I'm not a big fan of arrow functions. So what am I doing here, am I just cheating to save space in the slides? Well, it turns out, this particular scenario is a great illustration of why you want to use the arrow function.

[00:03:42]
Because I need this keyword inside of that function, and I need it to lexically adopt the parent context. I don't want it to define its own, I want it to adopt the parent context. That's exactly what the arrow context shines at doing, and so this is inappropriate, in my opinion, inappropriate usage of the arrow function.