I think one of the best reasons to use generators (co, or Bluebird coroutine) is when your promise chain has conditions according to which you have to do some other async operations or just go to next promise. Try to write some, and you will see ;). Btw: Best JS youtube channel. Love all your videos ;).
@mpj I think a better example to think about how you'd use generators might be to create a generator which, for each iteration, returns the first Monday of next month. The point is the generator can yield results ad infinitum, but the caller will only want a certain amount. The caller therefore yields the results until it's gotten all the Mondays it needs to do whatever it is that it needs to.
8 років тому+14
This comment brings up a great point. mpj’s exercise uses a generator as a protagonist (the piece of code that concerns itself with what he actually wants to get done) and run() as a generic utility that will blindly run his generators for as many iterations as they will yield. In that context, and especially as a dumb promise-resolver, I have to agree with mpj that generators aren't all that exciting. Your example is an inverse use of generators (and one that I suspect is more suited to its strengths), where they are treated as a utility that helps our protagonist functions achieve repetitive and possibly verbose functionality in an iterative manner until the real task at hand no longer requires it. They are certainly both valid uses of generators, of course, but your example illustrates where, in my opinion, their real value lies.
+Sylvain POLLET-VILLARD fundamentally very little. Generators _can_ be used to do things which are not as practical to do through recursion (multiple yields in multiple, nested loops if you're truly a masochistic e.g.), but some would just see a generator as being clearer than the recursive option. Similar to Alfonso's point, it also means that the _caller_ decides when to call it quits, whereas in recursion the recursive method must have a break case.
@mpj, @ianclark001: They're indeed great for implementing modular arithmetic (stuff which cycles around infinitely like clocks, weeks), especially when you need special conditions (like leap years). But generators are also extremely good for functional programming, especially when you combine various *composable* and *infinite* generators with a "limiting" generator and destructuring operators like let array = [...g()] and let (a,b) = g(). In Haskell, this is called Lazy Evaluation. You could view a generator as an infinite array, and you use various transformations/conditions on that infinite array, before requesting a manageable subset (comparable to the take function in Haskell). With generators, implementing list functions like transpose, intersperse and various folds for infinite data structures can look quite elegant: gist.github.com/okdewit/017ee6612ca116dc89a27192eb5e9987
I get that is a common use case but I don't get why we'd need generators for that? Why not just make this as a function that returns a function that you can call to get the next value? function makeMondayIterator(startMonth) { let lastMonth = startMonth return function next() { lastMonth++ // calculate and return monday of next month here } }
I feel like the current use of generators are just an overly complicated way of what "async await" will be in the next ES2016 - github.com/tc39/ecmascript-asyncawait. I agree that for now, promises are more straight forward for what most web developers are doing. Also thanks for adding the background music reference :)). I'm still trying to figure out the background music from ua-cam.com/video/lrf6xuFq1Ms/v-deo.html episode. Side note: You really moved me with the dramatic reading today... I am a new man... Keep up the good work!
Generators have an obvious use case, which you touch on at about 25:40: they let you write procedural, step-wise code (as you have in your generator example that gets passed to `run`) that use and depend on asynchronous code as though it were synchronous. HUGE win for simplifying code and avoiding callback hell. There are *no* visibly-explicit traditional callbacks in the generator code itself; the code that *runs* the generator (`run`, `co`, or whatever) takes care of that nastiness for you. As someone who has been writing code for a living since '79(!) and generally learns (or relearns) at least one or two new languages a year, I LOVE your videos. Great attitude and presentation skills, and the periodic diversions into less-than-obviously-related topics are welcome. Keep up the great work!
@@harisrg92 We can't cancel the promises with async/await, if you don't want to add a complex behaviour or your use case is simple you can go with async/await
Generators are fantastic for multi-step file system operations. You need to wrap most Node APIs using a lib like thunkify (e.g. thunkify(fs.readDir) ), but once that is done if you use co it is wonderful! For one example, imagine you just 1) yield readDir, check for what you want, then 2) yield readFile, then make your changes and 3) yield writeFile, but it must be zipped so then 4) yield archive, and then 5) yield ensureDir, and finally 6) yield move to send the file to the final location. You can imagine how deeply that would be nested. With generators, it's a piece of cake!
I know it is long time you left UA-cam, and I don't know if you still read the comment, but I have to tell you, your video is so helpful, well explained, and you are inimitable!! unique!!
I'm half into the video and I'm way too bothered by the fact that you mistakenly called that variable `anotherIterator` instead of `anotherIteration`. My OCD won't let me sleep tonight!
Being bothered is not the point. I think it's worth fixing this slips or typo or whatever named error. Because it's not an iterator. When someone watching this is new to the knowledge it might mix things up for him. IMO the fix would be helpfull.
the big advantage with generators is not that it can be used to make async code look synchronous but rather that can you lazily evaluate iterators on demand. Let's say you want a function that can generate all primes or just a very very large range. A generator allows you to on demand generate the next value without having to keep the entire sequence on hand (Which isn't possible with a list of all primes for example.)
Since generator can be used as iterator, it of course allows you to lazy evaluate code, but it is not everything. It is compatible with features like "for of" loop or array spread, and so with every algorithm that uses iteration methods. It gains the possibility to write simple asynchronous sequential code in declarative way, so no more callback hell. It allows you to write pure (side effect free) code by shifting the responsibility of evaluating not-pure functions inside generator up to the generator runner. Thanks to that, code becomes pure, predictable and a lot easier to test and maintain. This is of course not only exclusive for Promises.
Been trying to figure out what Generators are all about. This video makes me think they are overly complicated for no apparent reason. As mpj said in the end of the video, I too would like to see more practical uses of them.
if you have seen the latest episode of Silicon Valley you'll understand this: Its hard for me to have a relationship with someone who doesn't use semicolons.
The coroutine pattern demonstrated here is actually the underlying secret-sauce that makes async/await work in some future ES release (ES2017, hopefully).
Great examples. Freeze vid at 24:45 and ponder lines 20-28, especially line 25. The "next" method is called within a "then" within the "iterate" function that is used recursively to process a sequence of "yields" that control promises. It works - each promise is fulfilled before the next is invoked. .
Answering your question: I think the value of generators is around error handling: the ability to simply `try...catch` errors in asynchronous flows is really helpful.
Completely on board with your analysis of the usefulness of generators. I've always assumed previously that there was just something I didn't understand about them versus what I was doing with promises.
Mpj, you are a big inspiration for me. Thank you for that. I watch your vids on stuff I already know, just because I know you will have a good perspective on it.
Excellent demonstration of how generators work! I've "learned" generators several times already, every time I need to read some examples to refresh my memory (all that talk about coroutines always confuses me), this example is probably going to stick.
Love the video, but although recursion is a great feature, it should only be used when you can ensure the call stack is predictable and never going to exhaust the stack. A simple solution and always overlooked is to do a while around DONE then you will avoid a stack overflow problem, always try and implement with loops rather than recursion, can always handle many many more iterations.
Thank you for the clearest explanation of generators-as-the-new-promises usage! The piece I was missing was the need for an external "run" function. That explains the existence of all the "generator runner" libraries, like "co". From what I can tell, generators (which I think come to JS from Python?) were originally meant to solve the lazy-iterator problem. The whole terminology (iteration, next) makes sense for say, asynchronous queue processing. Their emergence as "the latest solution to callback hell" I think is premature. As seen in this example, it only moves the callback hell to solve other part of the codebase. Which is fine, if it's a green field application and you chose to do everything with "co" or one other the other generator runner libraries. But it's gonna be mental overload trying to combine code that's written for promises, generators, co, async, asynquence, and all these half-solutions that require a nonstandard library. :-( I'm hoping that the next version of JavaScript will provide a canonical solution to callback hell. I keep seeing references to "async/await" and wonder if that is going to be The One, our savior from (callback) hell, or just another false prophet?
`{value,done}` is not "anotherIterator", it's just an object with keys `value` and `done`, which is what iterators return ("done" is not mandatory until it is true, as per the spec). Very cool video, but I just wanted to point that out in case someone is confused.
Ok...I don't normally add to the internet conversation....but I think you're my favorite UA-camr! That intermission was blooming hilarious! Thanks for entertaining the heck out of me while still significantly helping me become a better developer! You're a hero! 🚀😁
The good thing about promises is that when you execute a then method to access the value of the resolved promise, you may return a value X to compose the promises. But you can also return another promise, in this case the value of the promise will be extracted and encapsulated into only one promise (like a chain in monads) therefore you can skip a "callback hell" an compose your functions. Also I agree with some guys that a better example will be something that needs to be executed forever and you just ask what you need. Other example would be to have an infinite scroll made with generators. You get access to the first 10 elements and add a counter, then you call for the next value that will get you the next ten. In this case generators are more exciting :)
Generators are really useful in contexts like KoaJS. I just used this for an api server I am writing. And while the hole promise thing is a nice benefit, where it really comes to use is saving you from callback hell when using a lot of Express-like Middlewares. It enables simple, clean code structure when passing down a request through your middlewares. I suggest taking a look at that :).
Thanks so much for this great explanation! I finally feel like I get the basic premise of generator functions! I also like that you were honest at the end of the video in regards to generators' usefulness...I've seen them mostly used/referred to as "pause-able functions" as you mention, which feels like more of a handy side-effect than the intended use case. It makes me realize that using generators for async flow control may be somewhat of a neat trick (at best) or an antipattern (at worst)...but at least I feel like I "get" them now :) Cheers!
I've been told by a guy that used to be on the ECMA standards committee that generators are a precursor to C#-style async-await functions. If so, that would be a great addition, IMO. Another use (as mentioned by someone else) are infinite lists. Not something you need every day, but might come in handy. Most examples of generators I've come across use the Fibonacci sequence as an example. And I also use a French press at work.
Nice one, generators is one of my favorite features to come. 'co' is the generator motor for Koa, and also offers a close abstraction to what is/will be async functions. Nice video mate, keep it up :)
I was just looking for some tutorials on this and I'm so glad you made some videos about ES6. Love your passion and they way you explain it all, thanks for the video's.
Hello! Thank you to make me finally understand co !! I never understand the co + generator thing... Now I understand that it's a early implementation of async function + await but without these keywords yet! :) I begin to use async + await (as it's supported by chrome 55), it's just awesome how the returned values are automagicaly transformed in Promise! By the way, I still don't understand well the use case of generators, I mean, the original use without co or any fake async function lib? I'm a bit disapointed, I thought you, funfunfunction, had given me some clues but you finally only speak of co (what is good still). What about generators with for .. of loops iterable interface and Symbol.iterator ?
Really like your videos and channel, thanks for making them! You often type out 'console.log()' you should make a snippet where you would type 'log' or 'l' and press tab, and it would automatically expand. Would save you time!
I intentionally don't do that, actually. I think that would distract from the content at hand. I don't use much hotkeys or plugins either, for the same reason. At worst, people get confused, and at best, they get impressed by the command and distracts from the subject that I'm talking about.
I used to use generators in Python in crawlers and they are very useful, because there is a lot of recursion, so it makes all responses available in a "flat way" .
I love your videos and recommend them to anyone that asks about functional javascript (especially for your first videos on .map, .filter, .reduce). And thanks for killing the music at 2:00! I know you need music as part of the production value of the video (along with your "lifestyle shots," etc....), but some of us can't focus while music is playing. Again, thanks. You are an excellent communicator.
It was funny, because I checked that it's Monday and there is no video from you, and when i came to your's channel there was a video added 1 minute ago. :-D I was faster than YT notifications. :-D
You did a bad job explaning generators -im wondering how many is getting it, watching this as their first generators video. That sad, you still awesome and keep doing what you are doing. You are a true gem for javascript developers
what a nice real world example for generators. since now, i only got introduced to them by number crunshing tasks, which is anyhow a very rare usecase for JavaScript from my point oft view. but this might be a usecase where generators prevail over promises. another nice side effect of combining promises and generators is the postponing of the promise until iterator.next gets called which otherwise only data.Task would do for you. but i see it like you: until now i had no real usecase for generators. thanks a lot for this good episode. :)
I used to thought generators are only for for-of loop, now I know another application of generators, thank to your video. Is there any other application of generators?
Awesome video as always!! The best use of Generators I've encountered is when using them with redux-sagas, IMO it would be very hard and nasty to try and implement redux-sagas using only Promises
Thanks for this video and all your other excellent videos! I have exactly the same feeling about generators. Right now the only sensible use case I can think of is combining them with promises. And in that respect, I feel that the readability of promises is just fine. Generators might give you more control over the execution of certain parts but I'm not exactly enlightened. I like the async and await spec much better. This makes it readable ánd simple in my opinion. I'm curious to see where this all leads to!
Nice episode! I don't see why I would use Generators yet unless for practical use I needed something to wait until it has finished running the fetch... I guess I need a practical use to go "hey, wow, I'm totally going to use that for x, y or z"...
Do you have the non-spead up/music overlay version of you refactoring your run function to make it recursive? It's cool to see the end result, but it would also be helpful to watch/listen to you working through a problem. I find the times that I tend to learn new cool stuff is when I'm watching another dev work through an issue.
Thanks for this video! I subscribed a couple days a ago and already had a couple of 'aha' moments after watching your vids. this is one is one of them :) oh and a small nag: I usually watch videos on 1.5-2 speed so background music is a bit annoying and here is also too loud (even though it was only in the beginning). But maybe its only me. Other then that great stuff. Thanks!
Great talk! BTW, how do you highlight part of screen? Which software or shortcut do you use to shade the whole screen and only highlight small round-scope of it?
I think promises are great, super useful, etc. That being said, generators do look like they are one step closer to abstracting away async patterns all together, which is the goal right?
In my opinion, I think the use case for generators would be to pull data as needed, not to make async code look synchronous. Imagine building Tinder; you might fetch 50 profiles from the API at once using a generator function, loop over the results and yield each. Once you call the generator, you store the iteration somewhere (perhaps a data store). Now in your UI, as the user swipes through each person's profile, you can simply call `iteration.next()`, to get the next person's profile card. Once `iteration.done` happens, you can recall the generator function with some sort of an offset and fetch 50 more users from the API.
+Johnny Ji yeah, I get how it can be used for that, but that seems to be pretty easily implemented without them to me. I don't understand the need for a separate language construct.
I don't think understanding promises is so crucial for understanding generators. I've understood and used generators in python where AFAIK promises are not implemented (or they're implemented in a module that's available for 3.5 or something like that, either way I haven't used them). Also much of the documentation and learning material I've seen about generators for python doesn't ever mention promises.
Hey, LOVE your videos. On the subject of successful implementations of generator functions, I believe RXJS's observers use these, and I love that library! I want to know your thoughts on the subject.
Thanks for the great video. It's almost as if you read my mind with your lessons, I was just planning to go through the co source code this weekend. Could you do a video about writing fluent syntax in JS, similar to what is being used in most of the assertion libraries?
learnt about generators from php, use case was reading a large file, you dont want it all in memory. if its like 2GB, other use case i can think of is if you had to do like loading large dataset for a graph you can load as needed. basically memory efficiency
I just found your channel and I LOVE IT! But I'm dying to know if you use any kind of framework for unit testing in JavaScript? I want to learn to unit test now so I can eventually use it everywhere, but I have no idea where to start and I don't want to spend too long learning a bunch of different tools (as per your super inspiring video on meta-work). You might have mentioned how you unit test somewhere in a comment or other video but I've only had time to go through about a tenth of your awesome content so far so I'm sorry if it's a common or annoying question.
+jasdfasdf asdfasdf i don't use any in particular. They are pretty much all the same to me and none of them offer any special benefit over the other. It's more about what you test than the testing framework, i.e. Having a testable architecture. I'm trying Redux at the moment and it's really really nice from a testing perspective.
I sound like I am being picky but it is a genuine question and not a snarky remark.... So with that :) In ES6 I understand that you should always declare a function before calling it. Here you call run() prior to declaring the run function. Is that OK because you are using ES5 function syntax to wrap the ES6 generator or have I just lost the thread completely? :) Amazing content as always!
There are no official "shoulds" introduced in ES6 that I am aware of, but in JavaScript, functions are hoisted to the top of their context before stuff is executed. Whether or not it's okay or not is something that you and your team has to decide, there are pros and cons to at and there is no central taste authority in JavaScript.
I agree that Generators as you show are just a fancy pants way of doing Async Await before it is standardised into the language. There is however another use for generators that is genuinely useful. You can use them to create infinite lazy sequences which are calculated as required. This is a common pattern in languages like Haskell where you can use them in combination with things like “zip” to feed your maps and reduces etc.
If you have a very big array of raw-data but you need to work with clean models in a loop, you don't want to map these data first on the classic way. Generators can be a solution to iterate over an array of models while you create it // --------------------------------- const data = [ {a: 1, b: 2}, {a: 2, b: 3}, {a: 3, b: 4} ]; function mapping() { return data.map(item => new Model(item)); } for(const item of mapping()) { console.log(item); } // --------------------------------- vs // --------------------------------- const data = [ {a: 1, b: 2}, {a: 2, b: 3}, {a: 3, b: 4} ]; function *generator() { for(const item of data) { yield new Model(item) } } for(const item of generator()) { console.log(item); } // --------------------------------- The solution with the generator only loop the whole data once, the solution with mapping will loop the whole data twice
If you’re watching this and haven’t used redux sagas yet...and I’m just learning... that’s answers the why. Basically causing side effects from your async actions.
I think Co isn't *essential* but it really helps simplify code, when you have a long chain of promises, and you have to generate a value up here, then pass it through to the last step, and you accomplish that by declaring a variable outside your promise chain and then assigning it's value in step 3 of your promise chain and using it in step 6.... The code runs on, much like this sentence. You can do it in 1/3rd the code with co.
Generators are not co-routines. There is a difference. The why -> Generators should be used with large data sets since they are lazy and thus much more memory efficient than adding everything into memory.
So, do I get this right, co is a library that uses generators to make using promises nice like it is today with async/await and today using it where async/await is available doesn't make much sense?
I heard from a friend who is working on this library: github/jfet97/jducers which is basically using generators, yield etc. that the performance is bad because yield is a slow or expensive operation. Thoughts?
We have a UI Data Layer that abstracts our Axios calls (they are complex, involve polling, etc). I'm considering using them to return a function that will cancel polling and then issue a cancellation token for the active request, then yield the results of the axios call. The alternative is to just return an object with a function that will cancel the request and a promise I can use to resolve the result. Thoughts?
Hi MPJ, I think generators are useful in case processing parent/child nodes. let me explain if u deal with Scrapy (python) if I crawl something like youtube channels so I will iterate over list of channels then yield each channel video into video parser. Let me know ur opinion
I think one of the best reasons to use generators (co, or Bluebird coroutine) is when your promise chain has conditions according to which you have to do some other async operations or just go to next promise. Try to write some, and you will see ;).
Btw: Best JS youtube channel. Love all your videos ;).
Agreed. I have encountered such situation and co just solved it gracefully without any repetition of code.
async / await.. much better
I still go back to your old vids to refresh on different subjects. I do miss you out there making content. Hope you are doing GREAT!
The music is a bit distracting in this video. Might be the volume.
Im 3 minutes into the video and the music is it playing lmao
I went to the middle of the video only to check if the music was still on and it wasn't, otherwise it would have been terribly annoying.
@@amypellegrini1732 yeah the music goes away at 1:57 thank God
@mpj I think a better example to think about how you'd use generators might be to create a generator which, for each iteration, returns the first Monday of next month. The point is the generator can yield results ad infinitum, but the caller will only want a certain amount. The caller therefore yields the results until it's gotten all the Mondays it needs to do whatever it is that it needs to.
This comment brings up a great point. mpj’s exercise uses a generator as a protagonist (the piece of code that concerns itself with what he actually wants to get done) and run() as a generic utility that will blindly run his generators for as many iterations as they will yield. In that context, and especially as a dumb promise-resolver, I have to agree with mpj that generators aren't all that exciting.
Your example is an inverse use of generators (and one that I suspect is more suited to its strengths), where they are treated as a utility that helps our protagonist functions achieve repetitive and possibly verbose functionality in an iterative manner until the real task at hand no longer requires it.
They are certainly both valid uses of generators, of course, but your example illustrates where, in my opinion, their real value lies.
what is the difference between using generators and using a recursive function in this example ?
+Sylvain POLLET-VILLARD fundamentally very little. Generators _can_ be used to do things which are not as practical to do through recursion (multiple yields in multiple, nested loops if you're truly a masochistic e.g.), but some would just see a generator as being clearer than the recursive option. Similar to Alfonso's point, it also means that the _caller_ decides when to call it quits, whereas in recursion the recursive method must have a break case.
@mpj, @ianclark001:
They're indeed great for implementing modular arithmetic (stuff which cycles around infinitely like clocks, weeks), especially when you need special conditions (like leap years).
But generators are also extremely good for functional programming, especially when you combine various *composable* and *infinite* generators with a "limiting" generator and destructuring operators like let array = [...g()] and let (a,b) = g().
In Haskell, this is called Lazy Evaluation. You could view a generator as an infinite array, and you use various transformations/conditions on that infinite array, before requesting a manageable subset (comparable to the take function in Haskell).
With generators, implementing list functions like transpose, intersperse and various folds for infinite data structures can look quite elegant:
gist.github.com/okdewit/017ee6612ca116dc89a27192eb5e9987
I get that is a common use case but I don't get why we'd need generators for that?
Why not just make this as a function that returns a function that you can call to get the next value?
function makeMondayIterator(startMonth) {
let lastMonth = startMonth
return function next() {
lastMonth++
// calculate and return monday of next month here
}
}
I got all excited this morning then told my wife that FunFunFuncition is my Saturday Morning Cartoons (But I usually have to go to work afterwards)
+TheShneek haha, awesome!
I feel like the current use of generators are just an overly complicated way of what "async await" will be in the next ES2016 - github.com/tc39/ecmascript-asyncawait. I agree that for now, promises are more straight forward for what most web developers are doing.
Also thanks for adding the background music reference :)). I'm still trying to figure out the background music from ua-cam.com/video/lrf6xuFq1Ms/v-deo.html episode.
Side note: You really moved me with the dramatic reading today... I am a new man...
Keep up the good work!
That's a fair feeling; the coroutine pattern (and its userland implementations) is actually what makes the async/await pattern viable in the future.
Generators have an obvious use case, which you touch on at about 25:40: they let you write procedural, step-wise code (as you have in your generator example that gets passed to `run`) that use and depend on asynchronous code as though it were synchronous.
HUGE win for simplifying code and avoiding callback hell. There are *no* visibly-explicit traditional callbacks in the generator code itself; the code that *runs* the generator (`run`, `co`, or whatever) takes care of that nastiness for you.
As someone who has been writing code for a living since '79(!) and generally learns (or relearns) at least one or two new languages a year, I LOVE your videos. Great attitude and presentation skills, and the periodic diversions into less-than-obviously-related topics are welcome. Keep up the great work!
Doesn't async await also do that? If I have to chose between async await and generators, I chose async await?
@@harisrg92 it based on generators
@@harisrg92 We can't cancel the promises with async/await, if you don't want to add a complex behaviour or your use case is simple you can go with async/await
Generators are fantastic for multi-step file system operations. You need to wrap most Node APIs using a lib like thunkify (e.g. thunkify(fs.readDir) ), but once that is done if you use co it is wonderful! For one example, imagine you just 1) yield readDir, check for what you want, then 2) yield readFile, then make your changes and 3) yield writeFile, but it must be zipped so then 4) yield archive, and then 5) yield ensureDir, and finally 6) yield move to send the file to the final location. You can imagine how deeply that would be nested. With generators, it's a piece of cake!
I know it is long time you left UA-cam, and I don't know if you still read the comment, but I have to tell you, your video is so helpful, well explained, and you are inimitable!! unique!!
I'm half into the video and I'm way too bothered by the fact that you mistakenly called that variable `anotherIterator` instead of `anotherIteration`. My OCD won't let me sleep tonight!
you are not alone XD
***** No, it's a good trait to have when doing things like naming variables. He's perfectly fine being annoyed by it.
Being bothered is not the point. I think it's worth fixing this slips or typo or whatever named error. Because it's not an iterator. When someone watching this is new to the knowledge it might mix things up for him. IMO the fix would be helpfull.
the big advantage with generators is not that it can be used to make async code look synchronous but rather that can you lazily evaluate iterators on demand. Let's say you want a function that can generate all primes or just a very very large range. A generator allows you to on demand generate the next value without having to keep the entire sequence on hand (Which isn't possible with a list of all primes for example.)
+harry3life sure, but I can simply do that with callbacks.
Since generator can be used as iterator, it of course allows you to lazy evaluate code, but it is not everything.
It is compatible with features like "for of" loop or array spread, and so with every algorithm that uses iteration methods.
It gains the possibility to write simple asynchronous sequential code in declarative way, so no more callback hell.
It allows you to write pure (side effect free) code by shifting the responsibility of evaluating not-pure functions inside generator up to the generator runner.
Thanks to that, code becomes pure, predictable and a lot easier to test and maintain.
This is of course not only exclusive for Promises.
Been trying to figure out what Generators are all about. This video makes me think they are overly complicated for no apparent reason. As mpj said in the end of the video, I too would like to see more practical uses of them.
I'm glad you talked about "why" you're convinced with generators. I agree and I'm usually more comfortable with promises and async/await.
if you have seen the latest episode of Silicon Valley you'll understand this: Its hard for me to have a relationship with someone who doesn't use semicolons.
+david howard ua-cam.com/video/Qlr-FGbhKaI/v-deo.html
+funfunfunction 😆
The example you're giving might also be solved with async/await if i'm not mistaken. Which makes it even harder to find good use cases for them.
The coroutine pattern demonstrated here is actually the underlying secret-sauce that makes async/await work in some future ES release (ES2017, hopefully).
Great examples. Freeze vid at 24:45 and ponder lines 20-28, especially line 25. The "next" method is called within a "then" within the "iterate" function that is used recursively to process a sequence of "yields" that control promises. It works - each promise is fulfilled before the next is invoked.
.
Answering your question: I think the value of generators is around error handling: the ability to simply `try...catch` errors in asynchronous flows is really helpful.
Completely on board with your analysis of the usefulness of generators. I've always assumed previously that there was just something I didn't understand about them versus what I was doing with promises.
Mpj, you are a big inspiration for me. Thank you for that. I watch your vids on stuff I already know, just because I know you will have a good perspective on it.
Great idea, I'll make a coffee and get back to watch you sir.
Excellent demonstration of how generators work! I've "learned" generators several times already, every time I need to read some examples to refresh my memory (all that talk about coroutines always confuses me), this example is probably going to stick.
Love the video, but although recursion is a great feature, it should only be used when you can ensure the call stack is predictable and never going to exhaust the stack. A simple solution and always overlooked is to do a while around DONE then you will avoid a stack overflow problem, always try and implement with loops rather than recursion, can always handle many many more iterations.
Thank you for the clearest explanation of generators-as-the-new-promises usage! The piece I was missing was the need for an external "run" function. That explains the existence of all the "generator runner" libraries, like "co".
From what I can tell, generators (which I think come to JS from Python?) were originally meant to solve the lazy-iterator problem. The whole terminology (iteration, next) makes sense for say, asynchronous queue processing. Their emergence as "the latest solution to callback hell" I think is premature. As seen in this example, it only moves the callback hell to solve other part of the codebase. Which is fine, if it's a green field application and you chose to do everything with "co" or one other the other generator runner libraries. But it's gonna be mental overload trying to combine code that's written for promises, generators, co, async, asynquence, and all these half-solutions that require a nonstandard library. :-(
I'm hoping that the next version of JavaScript will provide a canonical solution to callback hell. I keep seeing references to "async/await" and wonder if that is going to be The One, our savior from (callback) hell, or just another false prophet?
Laughing and learning all the time. That's how it should be, thank you for putting this up!
`{value,done}` is not "anotherIterator", it's just an object with keys `value` and `done`, which is what iterators return ("done" is not mandatory until it is true, as per the spec). Very cool video, but I just wanted to point that out in case someone is confused.
Ok...I don't normally add to the internet conversation....but I think you're my favorite UA-camr! That intermission was blooming hilarious! Thanks for entertaining the heck out of me while still significantly helping me become a better developer! You're a hero! 🚀😁
Great vid man! Very well done, I love the honesty in your presentation!! I love the question why at the end!
Love the videos! The background music is a bit distracting ;)
The good thing about promises is that when you execute a then method to access the value of the resolved promise, you may return a value X to compose the promises. But you can also return another promise, in this case the value of the promise will be extracted and encapsulated into only one promise (like a chain in monads) therefore you can skip a "callback hell" an compose your functions. Also I agree with some guys that a better example will be something that needs to be executed forever and you just ask what you need. Other example would be to have an infinite scroll made with generators. You get access to the first 10 elements and add a counter, then you call for the next value that will get you the next ten. In this case generators are more exciting :)
Generators are really useful in contexts like KoaJS. I just used this for an api server I am writing. And while the hole promise thing is a nice benefit, where it really comes to use is saving you from callback hell when using a lot of Express-like Middlewares. It enables simple, clean code structure when passing down a request through your middlewares. I suggest taking a look at that :).
Thanks so much for this great explanation! I finally feel like I get the basic premise of generator functions! I also like that you were honest at the end of the video in regards to generators' usefulness...I've seen them mostly used/referred to as "pause-able functions" as you mention, which feels like more of a handy side-effect than the intended use case. It makes me realize that using generators for async flow control may be somewhat of a neat trick (at best) or an antipattern (at worst)...but at least I feel like I "get" them now :) Cheers!
Yeild/Generator = Pausable Function. Thank for this great video made me. It makes sense now!
I've been told by a guy that used to be on the ECMA standards committee that generators are a precursor to C#-style async-await functions. If so, that would be a great addition, IMO.
Another use (as mentioned by someone else) are infinite lists. Not something you need every day, but might come in handy. Most examples of generators I've come across use the Fibonacci sequence as an example.
And I also use a French press at work.
That is what I've read too. Exciting times!
Nice one, generators is one of my favorite features to come. 'co' is the generator motor for Koa, and also offers a close abstraction to what is/will be async functions. Nice video mate, keep it up :)
I was just looking for some tutorials on this and I'm so glad you made some videos about ES6. Love your passion and they way you explain it all, thanks for the video's.
Hello!
Thank you to make me finally understand co !! I never understand the co + generator thing... Now I understand that it's a early implementation of async function + await but without these keywords yet! :)
I begin to use async + await (as it's supported by chrome 55), it's just awesome how the returned values are automagicaly transformed in Promise!
By the way, I still don't understand well the use case of generators, I mean, the original use without co or any fake async function lib?
I'm a bit disapointed, I thought you, funfunfunction, had given me some clues but you finally only speak of co (what is good still).
What about generators with for .. of loops iterable interface and Symbol.iterator ?
Really like your videos and channel, thanks for making them!
You often type out 'console.log()' you should make a snippet where you would type 'log' or 'l' and press tab, and it would automatically expand. Would save you time!
I intentionally don't do that, actually. I think that would distract from the content at hand. I don't use much hotkeys or plugins either, for the same reason. At worst, people get confused, and at best, they get impressed by the command and distracts from the subject that I'm talking about.
Hey man,
Long time listener, first time caller
I would love to hear you talk about css!!
keep up the great work
Agh you poured the coffee now I need to go get a coffee before I can watch this!
In regards to the why - it seems like they're also important because they simplify the process of creating your own iterable object.
Thanks for this one. Co now makes sense. And using it still doesn't make as much sense. But I now get it.
I used to use generators in Python in crawlers and they are very useful, because there is a lot of recursion, so it makes all responses available in a "flat way" .
I love your videos and recommend them to anyone that asks about functional javascript (especially for your first videos on .map, .filter, .reduce).
And thanks for killing the music at 2:00! I know you need music as part of the production value of the video (along with your "lifestyle shots," etc....), but some of us can't focus while music is playing.
Again, thanks. You are an excellent communicator.
+Benjamin Downs yeah, I generally try to tone it down when I need the full attention of people. ;)
Cool explanation about generators! Thanks for sharing it!
It was funny, because I checked that it's Monday and there is no video from you, and when i came to your's channel there was a video added 1 minute ago. :-D I was faster than YT notifications. :-D
You did a bad job explaning generators -im wondering how many is getting it, watching this as their first generators video. That sad, you still awesome and keep doing what you are doing. You are a true gem for javascript developers
Thanks very clear very organized and very simple
what a nice real world example for generators. since now, i only got introduced to them by number crunshing tasks, which is anyhow a very rare usecase for JavaScript from my point oft view. but this might be a usecase where generators prevail over promises. another nice side effect of combining promises and generators is the postponing of the promise until iterator.next gets called which otherwise only data.Task would do for you. but i see it like you: until now i had no real usecase for generators. thanks a lot for this good episode. :)
+Christian Hörauf yeah, perhaps I should find some semi-infinite stream case instead or something.
For those looking for an use case in the wild (and who know a bit about redux), redux-sagas makes great use of generator functions.
awesome tutorial for deep understanding
Awesome! Just one thing.
Command + K // This will clean your terminal and it will be easier to read (y)
+Eduardo Sganzerla I intentionally avoid using keyboard shortcuts, don't want to record keyboard. ;)
I used to thought generators are only for for-of loop, now I know another application of generators, thank to your video. Is there any other application of generators?
Taught me so much. Thank you!
Awesome video as always!! The best use of Generators I've encountered is when using them with redux-sagas, IMO it would be very hard and nasty to try and implement redux-sagas using only Promises
Generators were the step necessary to make async/await possible in ES7, which are very cool / useful / syntax friendly
Great scene play. Touching 🤯
U're awesome mate!!
Thanks a lot!
Thanks for this video and all your other excellent videos!
I have exactly the same feeling about generators. Right now the only sensible use case I can think of is combining them with promises. And in that respect, I feel that the readability of promises is just fine. Generators might give you more control over the execution of certain parts but I'm not exactly enlightened. I like the async and await spec much better. This makes it readable ánd simple in my opinion. I'm curious to see where this all leads to!
You, sir, are a poet!!! Thanks for the awesome videos, they make me less clueless :D
Love your videos. They're great fun to watch and I get to learn something too. Are there any other channels that you could recommend to us?
That was a great depiction of the battery pack! 😂
You are Awesome! Please do a video series on JavaScript design patterns and ECM6 if you can.
We should now ganerators if we wanna write on something like Koa. Funfunfunction, ty, your videos are very useful and fun
Nice episode! I don't see why I would use Generators yet unless for practical use I needed something to wait until it has finished running the fetch... I guess I need a practical use to go "hey, wow, I'm totally going to use that for x, y or z"...
Do you have the non-spead up/music overlay version of you refactoring your run function to make it recursive? It's cool to see the end result, but it would also be helpful to watch/listen to you working through a problem. I find the times that I tend to learn new cool stuff is when I'm watching another dev work through an issue.
Thanks for this video! I subscribed a couple days a ago and already had a couple of 'aha' moments after watching your vids. this is one is one of them :)
oh and a small nag: I usually watch videos on 1.5-2 speed so background music is a bit annoying and here is also too loud (even though it was only in the beginning). But maybe its only me. Other then that great stuff. Thanks!
Public: Hey MPJ can we get a Q and A?
MPJ: 6:10
Great talk!
BTW, how do you highlight part of screen? Which software or shortcut do you use to shade the whole screen and only highlight small round-scope of it?
+Morgan Cheng Mouseposé.
I think promises are great, super useful, etc. That being said, generators do look like they are one step closer to abstracting away async patterns all together, which is the goal right?
In my opinion, I think the use case for generators would be to pull data as needed, not to make async code look synchronous. Imagine building Tinder; you might fetch 50 profiles from the API at once using a generator function, loop over the results and yield each. Once you call the generator, you store the iteration somewhere (perhaps a data store). Now in your UI, as the user swipes through each person's profile, you can simply call `iteration.next()`, to get the next person's profile card. Once `iteration.done` happens, you can recall the generator function with some sort of an offset and fetch 50 more users from the API.
+Johnny Ji yeah, I get how it can be used for that, but that seems to be pretty easily implemented without them to me. I don't understand the need for a separate language construct.
I don't think understanding promises is so crucial for understanding generators. I've understood and used generators in python where AFAIK promises are not implemented (or they're implemented in a module that's available for 3.5 or something like that, either way I haven't used them).
Also much of the documentation and learning material I've seen about generators for python doesn't ever mention promises.
+Heller86 sorry, I should have said learning them in JS.
excellent....that was easy..nicely explained.
Hey what Microphone do you use? Sounds great :)
+ReaperPlayzLeague there is a behind the scenes episode
I liked the way of teaching.
Thank you! You are the smartest person I know.😀
Hey, LOVE your videos. On the subject of successful implementations of generator functions, I believe RXJS's observers use these, and I love that library! I want to know your thoughts on the subject.
Thanks for the great video. It's almost as if you read my mind with your lessons, I was just planning to go through the co source code this weekend.
Could you do a video about writing fluent syntax in JS, similar to what is being used in most of the assertion libraries?
learnt about generators from php, use case was reading a large file, you dont want it all in memory. if its like 2GB,
other use case i can think of is if you had to do like loading large dataset for a graph you can load as needed. basically memory efficiency
I just found your channel and I LOVE IT! But I'm dying to know if you use any kind of framework for unit testing in JavaScript? I want to learn to unit test now so I can eventually use it everywhere, but I have no idea where to start and I don't want to spend too long learning a bunch of different tools (as per your super inspiring video on meta-work).
You might have mentioned how you unit test somewhere in a comment or other video but I've only had time to go through about a tenth of your awesome content so far so I'm sorry if it's a common or annoying question.
+jasdfasdf asdfasdf i don't use any in particular. They are pretty much all the same to me and none of them offer any special benefit over the other. It's more about what you test than the testing framework, i.e. Having a testable architecture. I'm trying Redux at the moment and it's really really nice from a testing perspective.
I sound like I am being picky but it is a genuine question and not a snarky remark.... So with that :) In ES6 I understand that you should always declare a function before calling it. Here you call run() prior to declaring the run function. Is that OK because you are using ES5 function syntax to wrap the ES6 generator or have I just lost the thread completely? :) Amazing content as always!
There are no official "shoulds" introduced in ES6 that I am aware of, but in JavaScript, functions are hoisted to the top of their context before stuff is executed. Whether or not it's okay or not is something that you and your team has to decide, there are pros and cons to at and there is no central taste authority in JavaScript.
Love you dude! cheers from Brazil
thanks for the video
i use generators to avoid dealing with huge arrays of data, they allow me to deal with data by units
I agree that Generators as you show are just a fancy pants way of doing Async Await before it is standardised into the language.
There is however another use for generators that is genuinely useful. You can use them to create infinite lazy sequences which are calculated as required. This is a common pattern in languages like Haskell where you can use them in combination with things like “zip” to feed your maps and reduces etc.
boy, is this hard
What's the name of the font you're using, is it DEJAVU SANS MONO ? thank you
I really enjoyed your videos, thanks for doing this! :D
If you have a very big array of raw-data but you need to work with clean models in a loop, you don't want to map these data first on the classic way. Generators can be a solution to iterate over an array of models while you create it
// ---------------------------------
const data = [
{a: 1, b: 2},
{a: 2, b: 3},
{a: 3, b: 4}
];
function mapping() {
return data.map(item => new Model(item));
}
for(const item of mapping()) {
console.log(item);
}
// ---------------------------------
vs
// ---------------------------------
const data = [
{a: 1, b: 2},
{a: 2, b: 3},
{a: 3, b: 4}
];
function *generator() {
for(const item of data) {
yield new Model(item)
}
}
for(const item of generator()) {
console.log(item);
}
// ---------------------------------
The solution with the generator only loop the whole data once, the solution with mapping will loop the whole data twice
Great vid. Thanks for not editing out the full process of making the recursive function.
If you’re watching this and haven’t used redux sagas yet...and I’m just learning... that’s answers the why. Basically causing side effects from your async actions.
Thank for all the videos..Tusen takk..I have a question Jquery Ajax and Fetch which one you think is better beside the browser compatibility issues.
I think Co isn't *essential* but it really helps simplify code, when you have a long chain of promises, and you have to generate a value up here, then pass it through to the last step, and you accomplish that by declaring a variable outside your promise chain and then assigning it's value in step 3 of your promise chain and using it in step 6.... The code runs on, much like this sentence.
You can do it in 1/3rd the code with co.
+Anastasi Bakolias care to post an example? I'd love to see it in practice.
Generators are not co-routines. There is a difference. The why -> Generators should be used with large data sets since they are lazy and thus much more memory efficient than adding everything into memory.
Great explanation.
So, do I get this right, co is a library that uses generators to make using promises nice like it is today with async/await and today using it where async/await is available doesn't make much sense?
Pretty much yes
I heard from a friend who is working on this library: github/jfet97/jducers which is basically using generators, yield etc. that the performance is bad because yield is a slow or expensive operation. Thoughts?
Awesome video, @mpj! Thanks! :}
We have a UI Data Layer that abstracts our Axios calls (they are complex, involve polling, etc). I'm considering using them to return a function that will cancel polling and then issue a cancellation token for the active request, then yield the results of the axios call. The alternative is to just return an object with a function that will cancel the request and a promise I can use to resolve the result. Thoughts?
Hi MPJ, I think generators are useful in case processing parent/child nodes.
let me explain if u deal with Scrapy (python) if I crawl something like youtube channels so I will iterate over list of channels then yield each channel video into video parser.
Let me know ur opinion
May I know which software you use to record (and point the light on your cursor from time to time ;) ) ?? Thanks!
+Gabin Dsp see behind the scenes episode
Music stops at 1:55 you're welcome