I might be wrong but I'm pretty sure the method `return` and `throw` are part of the Generator's spec and not Iterator's. Also Generator's `next` takes an argument while Iterator's doesn't. Most structure expecting an "Iterator" usually uses the Generator method so if you had to implement one manually, sticking to the Generator specs makes sense. There is one use case were I find a difference through: if you share an Iterator between multiple loops (ad hoc queue/multi consumers), any loop breaking will causes a call to Generator's `return` method which will put the generator in a done state and end the other loop (no more value). If you have an iterator, there is no `return` method and the other loop will exhaust the iterator.
There is no need to call super if you’re talking about the Dog question. There isn’t any inheritance happening, so calling super in the constructor would be pointless it seems.
I’ve been working as a full stack dev for over 2 years now and I’ve never had to dive this deep. Am I doing something wrong ? I’m genuinely curious how this is useful in the real world if you’re not building apps from scratch
ehm, well promises are basically everywhere, classes are very useful in ts, and iterators are used under the hood of good old sagas, well that's basically single place I've come by iterators but anyway quite a handy base to build on
She basically has a quiz that are very similar to the questions I ask candidates when hiring other web developers during the theory interview round. I’m an architect at a fortune 30 company in finance, one of the top two banks in the world for reference. I’ll be checking this out, God willing. Seems like a lot of fun!
@@thi-m10 the question from video is a good example to understand the fundamentals as a fun exercise, but it's very terrible as an interview hard requirement test. It could be fun practice/warm up for both candidates and interviewer to go through the questions, but imply it's not a real thing to test against you. If you used this types of tricky code a lot in your codebase and it's the reason why you test the candidate. As a senior or whatever developer/interviewer you should be shameful for whatever you are doing now without good reasons. Speaking from the experience of that many cool kids know this type of tricky questions, neglect the fundamental, and actually try to apply them in real practice. Just like applying some crappy leetcode algos for simple stuffs. It's such a nightmare. The worst part, some senior devs are truly pretentious about knowing them, even some hacky prototype behavior you should never know or use, or terrible JavaScript design mistake from the past, which is completely irrelevant outside of JS.
Great visualisation for the event loop with the micro and macro tasks.
JavaScript is weird.
I might be wrong but I'm pretty sure the method `return` and `throw` are part of the Generator's spec and not Iterator's. Also Generator's `next` takes an argument while Iterator's doesn't.
Most structure expecting an "Iterator" usually uses the Generator method so if you had to implement one manually, sticking to the Generator specs makes sense.
There is one use case were I find a difference through: if you share an Iterator between multiple loops (ad hoc queue/multi consumers), any loop breaking will causes a call to Generator's `return` method which will put the generator in a done state and end the other loop (no more value).
If you have an iterator, there is no `return` method and the other loop will exhaust the iterator.
I love your work, and I'll be sharing it with my fellow teachers and my students. Bravo!
When you think you know javascript
that's when you know you don't😂
very well explained. thanks
thanks for the video, honestly it's in depth, clearly explained and a joy to use for review. Please do more
An excellent brush up concepts.
Jeez... She's good! 😲
Suggest to ask if super should be used
There is no need to call super if you’re talking about the Dog question. There isn’t any inheritance happening, so calling super in the constructor would be pointless it seems.
I’ve been working as a full stack dev for over 2 years now and I’ve never had to dive this deep. Am I doing something wrong ? I’m genuinely curious how this is useful in the real world if you’re not building apps from scratch
ehm, well promises are basically everywhere, classes are very useful in ts, and iterators are used under the hood of good old sagas, well that's basically single place I've come by iterators but anyway quite a handy base to build on
Just few words "Keep it coming, please".
That video is great, and You are great.
I subscribed with front end masters content was good but not having clear roadmap most of JavaScript is there which tutor I should start with ??
Please see our learning paths for guidance! frontendmasters.com/learn/ - all courses are placed in order depending what your goals are.
I see. The "return" keyword inside the generator functions is just to confuse people.
Not really. It's useless when you use them as plain iterators, but you could also use them as coroutines and actually utilise return value.
Does anyone know what tools was used for the visualization?
keynote
Great video Lyda! Thanks
nice video... just one little fix class Dog { construct(name) this.name = name ...
She basically has a quiz that are very similar to the questions I ask candidates when hiring other web developers during the theory interview round. I’m an architect at a fortune 30 company in finance, one of the top two banks in the world for reference. I’ll be checking this out, God willing. Seems like a lot of fun!
No one will ever compare two constructors or iterate a generator in production
@@bashovski But once you understand this you can avoid and identify many bugs and problems because you know how javascript works behind the scenes
@@thi-m10 I'll just use TypeScript to avoid worrying about a function returning an undesired type or a value. But I agree, it's not useless to know 👍
@@thi-m10 the question from video is a good example to understand the fundamentals as a fun exercise, but it's very terrible as an interview hard requirement test. It could be fun practice/warm up for both candidates and interviewer to go through the questions, but imply it's not a real thing to test against you.
If you used this types of tricky code a lot in your codebase and it's the reason why you test the candidate. As a senior or whatever developer/interviewer you should be shameful for whatever you are doing now without good reasons.
Speaking from the experience of that many cool kids know this type of tricky questions, neglect the fundamental, and actually try to apply them in real practice. Just like applying some crappy leetcode algos for simple stuffs. It's such a nightmare.
The worst part, some senior devs are truly pretentious about knowing them, even some hacky prototype behavior you should never know or use, or terrible JavaScript design mistake from the past, which is completely irrelevant outside of JS.
No this keyword shenanigans?
I need a new brain
It's not free. Sorry it's disappointing 😢
Nice voice and quiz! I didn't make a single mistake, I'm too experienced...
That last function looked a little iffy.
L
omg I'm so stupid. Javascript is so evil, I love it :v
What is being used for the visualizations?
in her channel she says Apple Keynote
I love these topics!
Thank you for this Lydia. That was great.
Awesome!