yield* Delegation and Lazy Sequences

## Eager versus lazy, concretely `[...].map(f).filter(p).slice(0, 5)` executes strictly left to right and to completion at each step. `map` visits every element and returns a full new array; `filter` then visits every element of *that* array and returns another full array; only then does `slice` throw away all but five results. Two properties follow: the source must be finite and already in memory, and every stage costs one allocation of roughly source size. A generator pipeline is *pull-based*. Nothing happens when you construct it. Work happens when the consumer calls `next()`, and each call travels back up the chain: the last stage asks the one before it for a value, which asks the one before that, until the source produces one. ```js function* naturals() { let n = 1; while (true) yield n++; // never ends — and that is fine } function* map(iterable, fn) { for (const x of iterable) yield fn(x); } function* filter(iterable, predicate) { for (const x of iterable) if (predicate(x)) yield x; } function* take(iterable, n) { if (n <= 0) return; let i = 0; for (const x of iterable) { yield x; if (++i === n) return; // stops pulling — the source is abandoned } } const squares = map(naturals(), n => n * n); const evens = filter(squares, n => n % 2 === 0); console.log([...take(evens, 5)]); // [ 4, 16, 36, 64, 100 ] ``` The source is infinite, yet the program terminates in microseconds and allocates no intermediate arrays. Only ten naturals were ever produced, because the filter needed ten to find five even squares. ## What actually happens per value For each of the five results, one `next()` at the `take` stage causes exactly one `next()` at `filter`, which loops calling `next()` on `map`, which calls `next()` on `naturals`. Values are interleaved, not batched: value 1 goes all the way through the pipeline before value 2 is produced. This is why the shape is often called a "vertical" traversal, against the "horizontal" stage-by-stage traversal of array methods. Memory follows directly. The array chain holds, at peak, the source array plus one intermediate per stage. The generator chain holds one value in flight plus each generator's own local state — constant, independent of how long the source is. ## When it matters - **Unbounded sources**: an ID generator, a random walk, a Fibonacci stream, a paging cursor. Array methods are simply not applicable. - **Early exit on a large source**: finding the first match in ten million records reads only as far as the match. `find` on an array does that too, but only for a single step — as soon as you need `map(...).find(...)`, the array version maps all ten million first. - **Big files or big result sets read in chunks**: each transformation stage adds no copy of the data. When the collection is small and already in memory, array methods are usually the better choice: they are clearer, they are heavily optimized in engines, and the allocation you save is trivial. ## Composition without an intermediate Because each stage takes an iterable and returns an iterable, stages compose in any order and `yield*` splices whole sub-sequences in without materializing them: ```js function* concat(...iterables) { for (const it of iterables) yield* it; // no array is built } ``` That is the same composability array methods give you, minus the copies — the trade being that each stage is a hand-written `function*` rather than a method call. ## The built-in version Since ES2025, iterator helpers give the same laziness without hand-rolling stages: `Iterator.prototype.map`, `.filter`, `.take`, `.drop`, `.flatMap` and `.toArray` exist on iterators, so `naturals().map(n => n * n).filter(n => n % 2 === 0).take(5).toArray()` produces the same result, lazily. They are available in Chrome 122+ and Node 22+; in older environments the hand-written generators above are the portable form, and interviewers still expect you to be able to write them. ## Traps to name - **Never spread an unbounded generator.** `[...naturals()]` and `Array.from(naturals())` both try to drain it and will hang until the process runs out of memory. The `take` must come before any materializing consumer. - **A generator object is one-shot.** After you consume `evens` once, a second spread yields nothing, because a generator object is its own iterator and it is exhausted. Wrap the pipeline in a function if you need to run it twice. - **Laziness delays side effects.** Building the pipeline runs no user code at all; a `console.log` or a fetch inside a stage happens only when someone pulls, and possibly never.