Generators in JavaScript 

Fantastic catch! I'll try set things straight on how exactly one is supposed to set done in upcoming videos.

This is because before it gets the 'value', it check of 'done'. And if its 'done' then the 'value' is NOT read and it just returns to the main function

I second this

I see what you did there. Well .done

+1

Thanks! You're right, but I intentionally stay away from hotkeys etc. in the videos as much as I can. Any time I use a tool etc in the videos I need to also spend time explaining it, and even when I do that, it distracts from the subject at hand.

... now!!

Yesss!

You totally missed any opportunity to say "We want them .next( ) ! "

I did not see one either until I saw async iterators being used to stream process data in ObservableHQ (beta.observablehq.com/@mbostock/introduction-to-asynchronous-iteration), then they arge bloody magnificent. We're going to be looking at that coming up, but we need to work ourselves up to that point first.

For me the best part of using generators (like redux-saga) is, that it makes it super easy to test different parts of your generator logic without the pain of mocking functions etc. Before redux-saga i used redux-thunk and to test this you need a lot of dependency injection. With redux-saga it feels much easier and straight forward.

GREAT question. Looking at the Mozilla developer documentation on the topic (developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols#The_iterator_protocol), it seems like one is actually not allowed to have the value property set to a non-object: "The next method always has to return an object with appropriate properties including done and value. If a non-object value gets returned (such as false or undefined), a TypeError (“iterator.next() returned a non-object value”) will be thrown."

Isn't it interesting that it also mirrors the behaviour of for loops. If you run a plain for loop with a condition like `i < 100`, then even though inside the loop the value of i never is more than 99, its value after the loop has completed is 100, not 99 (and this is what the spec says should happen). I never found that behaviour normal, but now I see that it is at least consistent.

hummm i just went to look at the doc u mentionned, it just says "The next method always has to return an object with appropriate properties including done and value", which just says you have to return {done, value} objects, but id does not specify if the last values sent back could be {value: "last", done: true} or {value:"last", done: false}, followed by {value: undefined, done: true}, since we don't have the hasNext() methods in java that allows you to know in advance if the iterator is over, i m still wondering. Personnaly in this case i would go for the last value as {value:"last, done: true}

I think the question was if it's possible to move the logic, whether another dragon shall be created, into the iterator call BEFORE the one where it's actually created and return done: false only if there will be another dragon. This way the consumer of the iterator knows whether he will get a dragon before he actually calls it (that's basically the information, that the java hasNext() method contains).

That was actually my first question too when I came across generators. If u look into stackoverflow you will find how we added a hasnext method. I think this should have been added in the core.

Yes. You can yield anything. This allows us to do really, really funky things with generators. When Generators arrived on the scene, async / await had not made it into the language, so the main big thing that the community used generators for was to implement async / await.... That said... it's a reeaaaaallly slippery slope though and often results in code that has so many layers of indirection that it's a lot harder to reason about than it would have been without iterators or generators, defeating the purpose of them. Generators are one of those things that are insanely cool and makes you feel incredibly clever, which is a good sign that one should look really critically at the code one produces and ask "is this really clearer?"

Thanks MPJ!

Not sure what you mean when you say view engine, sorry.

Its mentioned in the epsiode right after I show it for the first time :) also linked in the epsiode desc.

We haven’t started talking about async scenarios yet, so you couldn’t possibly get that scenario, don’t worry. We’ll get to it.

When you want to make things iterable.

Oh thats an idea. Its a lechturm 1917

thanks!

Generators is what is used under the hood to make async/await. Async/await is a very specific implementation of generator - before async / await existed in the language many used generators to implement it. But Generators are more general - async/await is limited to returning one single result, a generator can keep yielding, so it can be used to implement streams.

cool, thanks mate. :)

Generators has been around for several years now and can be safely used in production, and is by many people.

Its vs code

I think the video is excellent !. it's cool to wake up every morning with more of this... thank you very much!

and he is using quokka plugin

Yep. Two years of learning both for myself and the community. When it arrived on the scene people basically used them to implement async/await.

It's not just for explaining them - it's really how you do it. It's feels a bit weird, yes, but in a world that is pausable it makes a lot of sense.

Found it. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-ategZqxHkz4.html

Yeah, I made a previous video on generators where I was not very excited about them. I was mostly because at that point, all the community did was to implement a poor mans async / await, and all the tutorials was about that, and I find the value of async / await over promises, even when implemented natively, to be pretty limited. However, lately, I've been using observablehq.com a lot, and when you use async iterables when processing large amounts of data it becomes insanely nice.

Fun Fun Function fair enough. That makes sense. And thanks for the reply! As a side note, I've been a developer for about 15 years and I also came from a background of C# and Java. But I've always kind of hated JavaScript and other loosely typed scripting languages (though I've worked almost exclusively with it for three years now due to requirements of my job). But after listening to your musing on your opinion of JavaScript having come from a background of C#... I'm wondering if my dislike is coming from the stereotype of JavaScript not being a "real" programming language. As I dive deeper into it at work and grow even more comfortable with it. I completely agree with you. I feel far more productive with it. At the end of the day I consistently have something to show for it whereas with C# I could go a few days and only have laid the groundwork for a future awesome feature... thanks again for sharing your thoughts and wisdom. I watch every week.

yeah, have no idea how

actually I don't wanna know...

I have no idea, to be honest :)

That would not be an accurate translation to functional style. The functional variant of a generator would be a stream, i.e. a function where you pass in a callback function that gets called for every item in the stream. I have an episode on streams here (ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-UD2dZw9iHCc.html) You might ask - why not just return the items - i.e. process all the items at once? There might be many reasons, but the most common one where we use a stream or generator is if we can't process everything at once in memory, for example, if we're processing a 400GB dataset.

I mean something like this, it does maintain state in this simple example so its not "pure" const getSuperHeroes = ( era, offset = 0 ) => async () => fetchSuperHero( era, offset++ ) const nextOldSchoolSuperHero = getSuperHeroes(OLD_SUPERHERO_COLLECTION) const foo = await nextOldSchoolSuperHero()

That is what makes the function a generator instead of a normal function. I.e thats the core magic of the video. :)