2f:T67b,return_values_from_generator_are_ignored = md`## return values from a generator are ignored So if a generator's return values aren't used, why write a return statement in your generator at all? Check out the example [I linked above](https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/async%20%26%20performance/ch4.md#tale-of-two-questions), repeated below: \`\`\` function *foo(x) { var y = x * (yield "Hello"); // <-- yield a value! return y; } var it = foo( 6 ); var res = it.next(); // first \`next()\`, don't pass anything res.value; // "Hello" res = it.next( 7 ); // pass \`7\` to waiting \`yield\` res.value; // 42 \`\`\` The above example is *instructive* , it shows how the \`return\` keyword *does return a value* and how you **can manually retrieve that value** using \`.next()\` (the value \`42\` printed above...). But normal implementations **don't care about the generator's return \`value\` when \`done\` is true**. In other words, an **[Observable generator never uses or shows you a value \`return\`ed by your generator cell](https://observablehq.com/@observablehq/introduction-to-generators#cell-808)**. This is also true when [plain Javascript handles generators](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols#syntaxes_expecting_iterables) with iterable behavior (like \`for (const f of foo())\`), or with the spread operator: (\`[...foo()]\`), they [**ignore the value \`return\`ed by your generator.**](https://stackoverflow.com/questions/65871026/when-using-spread-syntax-on-a-generator-why-return-value-is-not-retrieved) Check out the examples below.`30:T441,observable_block_vs_observable_generator = md` ## Observable block vs Observable generator Also please remember the difference between an **Observable block** vs an **Observable generator cell** - If your Observable cell contains the \`yield\` keyword, it is interpreted as a [generator function](https://observablehq.com/@observablehq/introduction-to-code#cell-279) and therefore \`return\` value is ignored - If there is no \`yield\` keyword, your cell is interpreted as [a block](https://observablehq.com/@observablehq/introduction-to-code#cell-32), and the \`return\`ed value is used, the cell *becomes* the \`return\` value! We saw this in [the example above](#manually_get_returned_value_even_though_generator_is_consumed), an Observable block (even though it manually consumes a generator) *does return the final value*. But that's an Observable block that invokes generator... If that's confusing, consider the two examples below; identical except that one includes a \`yield\` statement *and* a \`return\` statement, where the other contains only the \`return\` statement... `31:T41c,values_sent_into_generator_next = md` ## values sent back into generator with \`.next(...)\` In discussing the \`return yield...;\` pattern, it's easy to get distracted by the use of the generator's [\`.next()\` function](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Generator/next) to send values *into a generator*. [Both answers here](https://stackoverflow.com/a/42309429/1175496) send values in with \`.next()\`... so does [this example](https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/async%20%26%20performance/ch4.md#tale-of-two-questions). However, sending values in has nothing to do with the way the \`return\` statement works - I hope that's clear after reading this Observable notebook. Nonetheless I was wondering, when Observable implicitly invokes our generator cells, *does it* send values into their \`.next()\` functions? If so, *what are the values* Observable sends back into our generator cells? I think Observable sends back the **value *just yielded* by the generator cell**. `;32:T80a,object_yielded_by_this_generator_cell = { let i = 0; let next_yield_value = undefined; let last_yield_substitute = undefined; let last_yielded_value = undefined; // mutability is an anti-pattern in Observable, but I'm doing it so I can display results outside the console // mutable keyword is not about modifying in-place, but literally re-assigning // yield_substitute_table_for_display.splice(0,yield_substitute_table_for_display.length); const display = []; const add_to_display = (step)=>{display.push(step && {step, next:JSON.stringify(next_yield_value), last_sub: !last_yield_substitute ? 'undefined': JSON.stringify(last_yield_substitute), next_is_last_sub:next_yield_value===last_yield_substitute, last:JSON.stringify(last_yielded_value), next_is_last: next_yield_value===last_yielded_value, this_val:this===undefined? 'undefined': JSON.stringify(this), dt: +new Date()})}; while (i < 3) { // yielding an object so I can check for [strict equality](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness) // strict equality comparison with objects check that they [refer to the same object](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Strict_equality#description) next_yield_value = { i_val: ++i }; add_to_display('before yielding'); // save the result of yielding (last_yield_substitute), i.e. what Observable passes back into the .next() function // apparently Observable passes back in *the same object that was just yielded* last_yield_substitute = yield Promises.delay(1000, next_yield_value); add_to_display('after yielding before storing'); // you could also/instead save the result of yielding yourself (last_yielded_value), // but this requires storing the yielded value into an intermediate variable (next_yield_value) last_yielded_value = next_yield_value; add_to_display('after yielding after storing'); add_to_display(); } mutable yield_substitute_table_for_display = display; }33:[] 2d:{"title":"On the return yield... pattern","cells":[{"id":56,"value":"# On the `return yield...` pattern","pinned":false,"hidden":false,"mode":"md"},{"id":51,"value":"md`Forked from [\"Pause a Generator\"](https://observablehq.com/@mbostock/pause-a-generator). Remember to check/uncheck the below box to pause/resume the execution`","pinned":false,"hidden":false,"mode":"ojs"},{"id":9,"value":"Inputs.bind(html``, viewof paused)","pinned":false,"hidden":false,"mode":"ojs"},{"id":0,"value":"md`\nFrom [this Stack Overflow discussion](https://stackoverflow.com/questions/42309185/js-generators-how-is-return-yield-different-from-yield/42309270?noredirect=1#comment131645306_42309270), @Bergi says:\n\n> ...@TheRedPea In the former example, it seems it's used to the same effect as \\`yield …; return\\`...,\n\n\\`yield …; return\\` does not produce the same effect if I substitute it *literally* (check and uncheck the box above, note the effect on \\`i_return_after_yield_no_braces\\` in the cell below, which *does not* behave like the original -- and I want to leave it that way to demonstrate what *not* to do)...` ","pinned":false,"hidden":false,"mode":"ojs"},{"id":5,"value":"i_return_after_yield_no_braces = {\n let i = this || 0;\n if (paused) yield i; return\n while (true) yield ++i;\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":37,"value":"md`...but I think what @Bergi *meant* was that the \\`return\\` keyword is just used to stop the flow of the program, relying on [a single statement](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/if...else#statement1) (with a single statement block braces aren't required.) [@Bergi later confirmed](https://stackoverflow.com/questions/42309185/js-generators-how-is-return-yield-different-from-yield/42309270?noredirect=1#comment131650087_42309270)`\n","pinned":false,"hidden":false,"mode":"ojs"},{"id":228,"value":"return_keyword_to_stop_flow_of_generator_functions = md`## \\`return\\` statements stop the flow of generator functions\nIn other words, the below cell would have the same effect (closing the \\`if\\` statement block **explicitly with braces** \\`{...}\\` so you can fit two statements in it:\n - the \\`yield\\` statement \n - *and* the \\`return\\` to **stop the flow of the function**\n\nNote the effect on \\`i_return_after_yield_with_braces\\` in the cell below... it matches the *original* behavior of \\`i\\`)\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":531,"value":"Inputs.bind(html``, viewof paused)","pinned":false,"hidden":false,"mode":"ojs"},{"id":45,"value":"i_return_after_yield_with_braces = {\n let i = this || 0;\n if (paused) { // <-- note the braces used here to accommodate multiple statements that follow\n yield i; \n return; // <-- note the return used here to stop the flow of the function from reaching the while(true) loop\n } \n while (true) yield ++i;\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":137,"value":"md`So we learned there's *nothing special about \\`return yield ...;\\`* \n\n - It doesn't rely on special magic where the \\`yield\\` values can be substituted into a generator when calling \\`.next()\\` ([more below](#values_sent_into_generator_next))\n - It doesn't matter that the \\`return\\` statement technically does return a value -- Observable **doesn't care about the value \\`return\\`ed from a generator!** ([more below](#return_values_from_generator_are_ignored))\n\nThe above \\`i_return_after_yield_with_braces\\` variation proves that. Our \\`return;\\` statement in cell \\`i_return_after_yield_with_braces\\` returns \\`undefined\\` -- but that doesn't break the behavior of the cell; Observable **never shows you the value \\`undefined\\`**\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":236,"value":"else_statement_to_stop_flow_of_generator_functions = md`\n## \\`else\\` statement can stop the flow of generator functions\n\nThe only purpose of the \\`return\\` statement above is to **prevent the flow of the function from reaching the infinite \\`while(true)\\` loop**. We could also do this by wrapping the rest of the function in an \\`else\\`. If we use an \\`else\\`, our code gets longer but there's no need for the \\`return\\` statement at all! \n\nI think this is part of @Bergi's point. Check out the cell \\`i_no_return_use_else_statement\\` below. It's the wordiest code so far, but the behavior is the same...`","pinned":false,"hidden":false,"mode":"ojs"},{"id":534,"value":"Inputs.bind(html``, viewof paused)","pinned":false,"hidden":false,"mode":"ojs"},{"id":19,"value":"i_no_return_use_else_statement = {\n let i_no_return_use_else_statement = this || 0;\n if (paused) {\n yield i_no_return_use_else_statement; \n } else {\n while (true) yield ++i_no_return_use_else_statement;\n }\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":69,"value":"md` So as long as we control the flow of the generator function correctly, **we don't need a \\`return\\` keyword**. We could use other flow-stopping keywords like \\`break\\` (any others?).\n\nIn geneartor the \\`return\\` keyword is implied if missing and there is nothing left for the function to do, as mentioned [here](https://github.com/getify/You-Dont-Know-JS/blob/1st-ed/async%20%26%20performance/ch4.md#tale-of-two-questions) \n\n > ...there's always an assumed/implicit return...\n\nIt reminds me of behavior when [\\`return\\` is omitted in plain Javascript functions in general](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/return)...). Plain Javascript functions (as in generator functions), \\`return\\` can stop the flow of the function and is implied when omitted.\n`\n","pinned":false,"hidden":false,"mode":"ojs"},{"id":80,"value":"$2f","pinned":false,"hidden":false,"mode":"ojs"},{"id":92,"value":"i_will_only_show_yielded_numbers_never_returned_string = {\n let i=0;\n while (i<10){\n yield i++;\n }\n return 'Observable will not show you this string value because the generator is finished (\\`done\\`: true) by this point';\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":98,"value":"function* i_generator_func_yields_numbers_returns_string(){\n let i=0;\n while (i<10){\n yield i++;\n }\n return 'Typical iterators will never fetch this value because the generator is finished (\\`done\\`: true) by this point';\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":102,"value":"md`When using the spread operator, you only see the integers yielded by the generator function, you [never see the string \\`return\\`ed](https://stackoverflow.com/q/65871026/1175496) by the [\\`i_generator_func_yields_numbers_returns_string\\` generator function](#i_generator_func_yields_numbers_returns_string): \n\n${[...i_generator_func_yields_numbers_returns_string()]}`","pinned":true,"hidden":false,"mode":"ojs"},{"id":104,"value":"{\n for (const i of i_generator_func_yields_numbers_returns_string()){\n console.warn(i);\n }\n return md`The [\\`for (const i of generator)\\` loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of) in this cell is finished but check your console, when this cell is executed your console logs only *integer values* \\`yield\\`ed by the generator, your console never logs a string \\`return\\`ed by the [\\`i_generator_func_yields_numbers_returns_string\\` generator function](#i_generator_func_yields_numbers_returns_string)`;\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":349,"value":"md`More on how Observable handles generators, including how they implement the iterator protocol, [here](https://observablehq.com/@observablehq/generator-cells-functions-and-objects#cell-25)`","pinned":false,"hidden":false,"mode":"ojs"},{"id":110,"value":"md`As [@Gabriele Petrioli points out here](https://stackoverflow.com/questions/65871026/when-using-spread-syntax-on-a-generator-why-return-value-is-not-retrieved#comment116464313_65871026) and mentioned in the [MDN docs](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators#done)\n\n > \"\\`done\\`: This is true if the last value in the sequence has **already been consumed**.\"\n\nYou *could* ignore the fact that the last value was consumed -- you could **manually** get the \\`return\\` value yourself by using \\`.next()\\` -- where it is wrapped in an object like: \\`{ value: ..., done: true }\\`\n\n...but you need to act on the \\`value\\` even though \\`done\\` is **\\`true\\`**, which is *not* typical implementation...`","pinned":false,"hidden":false,"mode":"ojs"},{"id":117,"value":"manually_get_returned_value_even_though_generator_is_consumed = {\n const i_generator = i_generator_func_yields_numbers_returns_string();\n let i_value;\n // keep *manually* iterating through the generator yourself; even until you've exhausted it, and retrieved the very last value it returned...\n while (i_value = i_generator.next()){\n if (i_value.done) break;\n }\n // then return the very last value from your generator\n return md`In this example, we get the \\`return\\`ed value **manually** with \\`next()\\` and **ignore the fact that the generator was finished (\\`done\\`: true)**...we do something with the value anyway. Here it is:\n\n > ${i_value.value}`;\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":191,"value":"So if Observable generators never use a return value, why use a return statement at all? \n - Remember a `return` statement **still controls the flow of the generator function** which is important\n - Also the `return yield` pattern is the **least wordy** way of controlling the flow of the generator function (no braces needed; no `else` statement needed)\n\nAnd why use the `return yield...` pattern specifically? Maybe just because it's been established as a pattern - established as the \"Observable way\" to **pause generators** based on some condition!","pinned":false,"hidden":false,"mode":"md"},{"id":218,"value":"$30","pinned":false,"hidden":false,"mode":"ojs"},{"id":305,"value":"observable_block_no_yield_keyword_return_value_used = {\n return 'hi';\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":308,"value":"observable_generator_has_yield_keyword_return_value_ignored = {\n yield 0;\n return 'hi';\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":449,"value":"md`But even though the \\`return\\`ed *value* is ignored, the \\`return\\` statement still stops teh flow of the function, ensuring a yield *after* the \\`return\\` would never execute:`","pinned":true,"hidden":false,"mode":"ojs"},{"id":452,"value":"observable_generator_has_yield_keyword_return_value_ignored_subsequent_yield_never_executed = {\n yield 0;\n // you will never see this 'hi' value because while the line is executed, the generator is already done;\n // Observable never consumes the value from a generator's return statement\n return 'hi';\n // you will never see this 1 value because this yield is never executed, the generator has already consumed all its values and is marked as done as of the return statement\n yield 1;\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":318,"value":"$31","pinned":false,"hidden":false,"mode":"ojs"},{"id":331,"value":"$32","pinned":true,"hidden":false,"mode":"ojs"},{"id":385,"value":"md`\n| step | next | last_sub | next_is_last_sub | last | next_is_last| this_val | dt |\n|----------------|-----------|---------------|---------------------|-----------|-------------|---------------|-------------------|\n${yield_substitute_table_for_display.map(_=>`|${(_?[_.step, _.next, _.last_sub, _.next_is_last_sub, _.last, _.next_is_last, _.this_val,_.dt] : Array(8).fill('-loop-')).join('|')}|`).join('\\n')}\n`\n //Inputs.table(mutable yield_substitute_table_for_display)","pinned":false,"hidden":false,"mode":"ojs"},{"id":539,"value":"You can see in native Javascript, iterating a generator does not send any value into `.next()`, if you ran this code in your console you'd see it log 11x `undefined`'s:\n\n```\nfunction* gen(){\n let i=0;\n while (true){\n // to demonstrate that when using generators as iterables, for (const i of gen())\n // Javascript does *not* send values back in, with .next(...)\n console.error(yield i++);\n }\n}\n\nfor (const i of gen()){\n if (i>10) break;\n}\n```","pinned":false,"hidden":false,"mode":"md"},{"id":369,"value":"this_behavior_vs_next_behavior = md `\n## \\`.next()\\` behavior vs \\`this\\` behavior\n\nIn other words, maybe generators' last-passed-in (aka substitute) values work similar to the way [Observable assign the previous evaluations' value to the \\`this\\` keyword](https://observablehq.com/@tmcw/untitled/5) Note:\n\n - Only Observable blocks have special \\`this\\` behavior; not plain Javascript. \n \nBe careful to clarify \\`this\\`: it stores the previous value of the cell, \n - **not** when a cell is re-run (i.e. Shift+Enter)\n - **not** when a cell loop is re-run (like \\`while (true)\\`)\n\n...but when the cell is **reactively re-evaluated**, like when one cell references another cell whose value changes:\n - when the referenced cell is re-evaluated\n - or when the referenced cell is a view (an input; (\\`viewof\\`)) and the user changes its value\n - **as in the [\"Pause a Generator\"](https://observablehq.com/@mbostock/pause-a-generator) example itself!*\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":382,"value":"mutable yield_substitute_table_for_display = [];","pinned":false,"hidden":false,"mode":"ojs"},{"id":525,"value":"md`When a one-\\`return\\` or one -\\`yield\\` statement is reactively / input re-evaluated, then they are very similar to each other, and both can access the previously evaluated value via \\`this\\``","pinned":true,"hidden":false,"mode":"ojs"},{"id":457,"value":"observable_block_this_keyword_references_other_cell = {\n other_cell_value_changes_on_interval;\n return [other_cell_value_changes_on_interval, JSON.stringify(this)]; \n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":487,"value":"observable_generator_this_keyword_references_other_cell = {\n other_cell_value_changes_on_interval;\n yield [other_cell_value_changes_on_interval, JSON.stringify(this)]; \n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":476,"value":"other_cell_value_changes_on_interval = {\n let i = 0;\n while (i<3){\n yield Promises.tick(1000, i++);\n }\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":491,"value":"md`So now I can test the theory that \\`this\\` is the same as the last-sent-in (aka substituted) yield value...Hmmm, not sure how I could check that theory without using mutable to store the value of the yield elsewhere, or causing infinite recursion...`","pinned":false,"hidden":false,"mode":"ojs"},{"id":495,"value":"// might cause infinite recursion trying to check for object equality *within* ths generator block\n// observable_generator_this_keyword_references_other_cell_check_this = {\n// other_cell_value_changes_on_interval;\n// // oops risks reacting to it, infinite recurison:\n// // console.error(observable_generator_this_keyword_references_other_cell_check_this_store_substitute, this)\n// mutable observable_generator_this_keyword_references_other_cell_check_this_store_substitute = (yield [other_cell_value_changes_on_interval, JSON.stringify(this)]);\n// }","pinned":true,"hidden":false,"mode":"ojs"},{"id":542,"value":"md`I couldn't figure out a way to show strict object equality by directly comparing *within a generator cell*, so I used console.error below. Note:\n - the value of \\`this\\` remains the same before *and* after the \\`yield\\`\n - the last-sent-in (aka substituted) \\`yield\\` value logged at iteration \\`n-1\\` seems to be *the same* as the value of \\`this\\` logged at iteration \\`n\\`\n`\n","pinned":false,"hidden":false,"mode":"ojs"},{"id":515,"value":"observable_generator_this_keyword_references_other_cell_check_this_simple = {\n other_cell_value_changes_on_interval;\n // oops risks reacting to it, infinite recurison:\n // console.error(observable_generator_this_keyword_references_other_cell_check_this_store_substitute, this)\n console.error(this);\n console.error(yield [other_cell_value_changes_on_interval, this]);\n console.error(this);\n console.error('===');\n}","pinned":true,"hidden":false,"mode":"ojs"},{"id":529,"value":"viewof paused = Inputs.input(false) /* Moving this here so I can repeat the checkbox in multiple places for the user's convenience using [Inputs.bind](https://observablehq.com/@observablehq/synchronized-inputs) */","pinned":true,"hidden":false,"mode":"ojs"},{"id":568,"value":"","pinned":true,"hidden":false,"mode":"ojs"}],"files":"$W33","stdlib":"1","titling":"auto"}