すなわち、私はこれをどのように表現しますか:
function *(next) {}
矢印付き。考えられるすべての組み合わせを試しましたが、ドキュメントが見つかりません。
(現在、ノードv0.11.14を使用)
まず最初に 矢印関数() => {}
はインライン関数function(){}
を置き換えるものではなく、それらは異なります。インライン関数は単なる関数であるため、問題は矢印関数とインライン関数の違いです。
矢印関数式(矢印関数とも呼ばれる)は、関数式に比べて構文が短く、独自の
this
、arguments
、super
、またはnew.target
をバインドしません)。矢印関数は常に匿名です。
より簡単な詳細 こちら
https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Functions/Arrow_functions
yieldキーワードの使用
yield キーワードは、矢印関数の本体では使用できません(さらにネストされた関数内で許可されている場合を除く)。結果として、矢印関数はジェネレーターとして使用できません。
yield
なしの generators は意味をなさないことに注意してください。
http://tc39wiki.calculist.org/es6/arrow-functions/
矢印関数は
this
を字句的にバインドし、Block本文の場合はreturn
をバインドして、すぐに囲む矢印関数から戻るようにし、break
およびcontinue
がすぐに囲む矢印関数の外部のステートメントを参照できないようにします。Identifier一次式
arguments
は、矢印関数の本体(式またはブロック形式)で使用できません。同様に、
yield
は矢印関数の本体では使用できません。矢印をジェネレーターにすることはできず、深い継続は必要ありません。
矢印関数の収量はセマンティックエラーをスローします: http://www.ecma-international.org/
最後に、理由はECMA6の実装が非常に複雑であることです。 C#では、同様の reasons に対してもこれを許可していません。
上記の esdiscuss.org および 2013年11月のEcma TC39委員会ES6会議ノート に関する議論に加えて、発電機矢印は2016年9月のES7会議で再訪しました [1][2] 。さまざまな構文(主に=*>
および=>*
)の長所と短所、およびこの機能の正当化とユースケースの欠如について議論した後、彼らは次のような結論に達しました。
- 委員会からはある程度の関心が寄せられていますが、この機能は新しい構文を追加しても重みがかからないという懸念があります。
- [Domenic Denicola]の非同期イテレーションの提案の一環として、少なくとも__
=>*
をステージ0に到達できるかどうかを確認するために、3日目に再訪する計画を立てます。
ジェネレーター矢印の提案は、ブレンダンアイヒとドメニックデニコラをチャンピオンとしてステージ1に移動しましたが、関連する tc39/proposals リポジトリはまだ存在しません。さらなるニュースのために、ステージ3非同期反復の提案が完了するまで待たなければならないと思います。
私も同じ質問をしていて、ここに来ました。投稿とコメントを読んだ後、矢印関数でジェネレーターを使用することはあいまいに思えます:
const generator = () => 2*3; // * implies multiplication
// so, this would be a confusing
const generator = () =>* something; // err, multiplying?
const generator = () =*> ... // err, ^^
const generator = ()*=> ... // err, *=3, still multiplying?
const generator=*()=> ... // err, ^^
const generator = *param => ... //err, "param" is not fixed Word
これが、矢印関数に関連してジェネレーターを実装しなかった大きな理由かもしれません。
しかし、私がそれらの1人だった場合、次のように考えることができました。
const generator = gen param => ... // hmm, gen indicates a generator
const generator = gen () => ... // ^^
これは、非同期関数があるように感じます。
const asyncFunction = async () => ... // pretty cool
通常の関数ではasyncキーワードが存在するため、矢印関数がそれを利用しているため、async () =>
はasync function()
に見える可能性が高いためです。
しかし、gen
やgenerator
のようなキーワードはなく、alas arrow関数はそれを使用していません。
結論:
矢印関数でジェネレータを実装する場合でも、コアjsのジェネレータ構文について再考する必要があると思います。
generator function myfunc() {}
// rather than
function* myfunc() {} // or, function *myfunc() {}
そして、これは大きな失敗です。そのため、矢印関数をジェネレーターから締め出すのは非常にクールです。
次の @ Bergiコメント :
いいえ。矢印関数は軽量で(たとえば.prototypeを持たない)、多くの場合1ライナーであることが想定されていますが、ジェネレーターはほとんど逆です。
使用するジェネレーターの目的はrun-stop-runであると言うので、プロトタイプ、レキシカルなこれなどを気にする必要はないと思います。
私はこれが非常に遅いことを知っていますが、別の考えられる理由は構文かもしれません。 (*() => {})
は動作するかもしれませんが、(9 ** () => {})
はどうですか?それは、NaN
を返す矢印関数の9乗ですか、それともNaN
を返すジェネレーター矢印関数の9倍ですか?ここで別の回答で言及されているように、=>*
のようないくつかの代替構文で実行できますが、実装時にジェネレーター関数の構文(たとえば、function* () {}
と{ *genMethod() {} }
)の一貫性を維持したい場合があります。言い訳ではありませんが、その理由です。
Redux-sagaには素敵な回避策があります
import { call, all } from 'redux-saga/effects';
function* gen() {
yield all([].map(() => {
return call(....);
}));
}