私のお気に入りの提案:(今日、私たちは本当にthis無料プログラムを書くことができます。

参考までに、TC39の提案： https ：

提案はまだステージ0でもないというわけではありません。 それが言語セマンティクスに追加された場合、その他の詳細は変更される可能性があります。

これは私が最初に思う（Enumやモジュールシステムのようないくつかの古いものを除いて）が、これを実装するtypescriptは、それをより可視化し、残りのecmaエコシステムでの需要を高めることができますか？

https：//vanslaars.io/post/create-pipe-function / ...に触発された行方不明のパイプラインオペレーターの回避策を共有したかっただけ

同期減速を備えたSyncPipe

// SyncPipe with synchronous reduction
type SyncPipeMapper<T, U> = (data: T | U) => U;
type SyncPipeReducer<T, U> = (f: SyncPipeMapper<T, U>, g: SyncPipeMapper<T, U>) => SyncPipeMapper<T, U>;
type SyncPipe<T, U> = (...fns: SyncPipeMapper<T, U>[]) => SyncPipeMapper<T, U>;
function createSyncPipe<T, U>(): SyncPipe<T, U> {
    const syncPipe: SyncPipeReducer<T, U> = (f: SyncPipeMapper<T, U>, g: SyncPipeMapper<T, U>) => (data: T) => g(f(data));
    return (...fns: SyncPipeMapper<T, U>[]): SyncPipeMapper<T, U> => fns.reduce(syncPipe);
}

// Example:
function testSyncPipe(num: number): number {
    const addOne: SyncPipeMapper<number, number> = (data: number): number => {
        return data + 1;
    }
    const syncPipe: SyncPipe<number, number> = createSyncPipe();
    const syncWaterfall: SyncPipeMapper<number, number> = syncPipe(
        addOne,
        addOne,
        addOne,
    );

    // Does the equivalent of num+3
    const lastnumber: number = syncWaterfall(num);
    return lastnumber;
}

非同期リダクションを備えたAsyncPipe

// AsyncPipe with asynchronous reduction
type AsyncPipeMapper<T, U> = (data: T | U) => Promise<U>;
type AsyncPipeReducer<T, U> = (f: AsyncPipeMapper<T, U>, g: AsyncPipeMapper<T, U>) => AsyncPipeMapper<T, U>;
type AsyncPipe<T, U> = (...fns: AsyncPipeMapper<T, U>[]) => AsyncPipeMapper<T, U>;
function createAsyncPipe<T, U>(): AsyncPipe<T, U> {
    const asyncPipe: AsyncPipeReducer<T, U> = (f: AsyncPipeMapper<T, U>, g: AsyncPipeMapper<T, U>) => async (data: T) => g(await f(data));
    return (...fns: AsyncPipeMapper<T, U>[]): AsyncPipeMapper<T, U> => fns.reduce(asyncPipe);
}

// Example:
async function testAsyncPipe(num: number): Promise<number> {
    const addOne: AsyncPipeMapper<number, number> = async (data: number): Promise<number> => {
        return data + 1;
    }
    const asyncPipe: AsyncPipe<number, number> = createAsyncPipe();
    const asyncWaterfall: AsyncPipeMapper<number, number> = asyncPipe(
        addOne,
        addOne,
        addOne,
    );

    // Does the equivalent of num+3
    const lastnumber: number = await asyncWaterfall(num);
    return lastnumber;
}

非同期リダクション付きパイプ（簡略化）

私はほとんどの場合これを使用します：

// Pipes with asynchronous reduction
type PipeMapper<T> = (data: T) => Promise<T>;
type PipeReducer<T> = (f: PipeMapper<T>, g: PipeMapper<T>) => PipeMapper<T>;
type Pipe<T> = (...fns: PipeMapper<T>[]) => PipeMapper<T>;
function createPipe<T>(): Pipe<T> {
    const pipePipe: PipeReducer<T> = (f: PipeMapper<T>, g: PipeMapper<T>) => async (data: T) => g(await f(data));
    return (...fns: PipeMapper<T>[]): PipeMapper<T> => fns.reduce(pipePipe);
}

// Example:
async function testPipe(num: number): Promise<number> {
    const addOne: PipeMapper<number> = async (data: number): Promise<number> => {
        return data + 1;
    }
    const pipe: Pipe<number> = createPipe();
    const waterfall: PipeMapper<number> = pipe(
        addOne,
        addOne,
        addOne,
    );
    // Does the equivalent of num+3
    const lastnumber: number = await waterfall(num);
    return lastnumber;
}

これがお役に立てば幸いです。

@PublicParadiseあまりにも多くのボイラープレート：p

私は間違いなくこの演算子のいくつかの変形を言語で見たいと思いますが、それに対する認識された必要性は、現在のECMAScriptの2つの異なる制限から来ています。

1つ目は、回避するのが非常に難しく、言語で対処することさえ困難です。つまり、組み込みオブジェクトを衛生的な方法で拡張できないことです。

ただし、2つ目は言語レベルのサポートをまったく必要とせず、実際に修正することができます。標準ライブラリは親切に貧血と呼ぶことができます。

MaximallyMinimalは完全な失敗です。

言語でArray.prototype.flatMapを取得するのに、なぜ何ヶ月も何ヶ月もの議論が必要なのですか？

これは1つの方法であり、最初から存在している必要があり、追加する必要があることは明らかです。

たぶんArray.prototypeは6年以内にgroupByメソッドを持つでしょう。

これまでに、これにはいくつかのbabelの実装があり、TC39の提案に沿って役立つことを願っています。

• https://github.com/michaelmitchell/babel-plugin-pipe-composition
• https://github.com/miraks/babel-plugin-pipe-operator

今はステージ1です

それで、この美しさがTSに入るチャンスはありますか？ F＃と一致します。 <3

例外はありますが、プロポーザルがTypeScriptとタイプにとって_重要_である場合、プロポーザルは通常、TypeScriptのTC39ステージ3に到達するまで実装されません。これは、プロポーザルが十分に安定していないため、重大な破損やリグレッションが発生しないことを保証するためです。

コアチームの誰もこの問題についてまだコメントしていませんが、ステージ3の前に実装を検討するのに十分な_重要_ではないと思います。最も重要なのは、TC39でチャンピオンと提案をサポートすることです。

TSだけがこの演算子をパイプでつなぐオプションを持っていれば、プラグインを備えたbabelがそれを処理できるようになります。
または、post-cssのように独自の構文プラグインがありました。 プリミティブ演算子を待つのに数年かかるのは多すぎます。

@garkin ：ここでの課題は、TSが型安全性を提供する仕事をするためにコードを理解する必要があることです。これは、理解できないランダムなコードとうまく組み合わされません。 マクロ（＃4892）を取得する場合を除いて、マクロを取得する場合は、コードにコンパイルするだけで理解できます。 しかし、標準ライブラリのかなりの数のビットがまだatmを入力するのが難しいので、ロードマップではまだそれを期待していません。

Babelがtypescriptを理解したので、Babelを実行できます。
typescript

2017年10月26日19:01、「TychoGrouwstra」 [email protected]は次のように書いています。

@garkin https://github.com/garkin ：ここでの課題は、TSが
型安全性を提供するというその仕事をするためのコードを理解しますが、それはしません
理解できないランダムなコードとうまく組み合わせる。 取得する場合を除いて
マクロ（＃4892 https://github.com/Microsoft/TypeScript/issues/4892 ）、
その場合、それはそれが理解するコードにコンパイルするだけです。 しかし、私はしません
標準のかなりの数のビットとして、まだロードマップ上でそれを期待してください
ライブラリはまだatmを入力するのが難しいです。

—
スレッドを作成したため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment-339748284 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZQTO6UiVHbrM6SRwaBhm8obaa3R7e9ks5swMkCgaJpZM4OzVEg
。

Babelがtypescriptを理解したので、Babelを実行できます。
typescript

ビルド時間の2倍：p

typescriptが単なるBabelプラグインであれば、必要はありません。
両方のプログラムをパイプでつなぐ

2017年10月26日20:16、「AlexGalays」 [email protected]は次のように書いています。

Babelがtypescriptを理解したので、Babelを実行できます。
typescript

ビルド時間の2倍：p

—
スレッドを作成したため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment-339769856 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZQTEArBw8jj0BcZFM2yLj5ErfbtNrgks5swNqagaJpZM4OzVEg
。

@graingert ：持っているのは良いオプションです、私はこれを調査します。
残念ながら、VisualStudioCode、Webstorm、およびその他のIDEで使用されるtypescript Language ServiceAPIでは機能しません。

「TSプラグイン」に関しては、たとえば、TS構文を理解し、ステートメントと同等の強い型を生成するパイプ演算子用の単純な（事前）トランスパイラーを使用して、目的の結果を簡単に達成できます。 型チェックなどで問題なくコンパイルできます。

そのためのWebpack構成は、次のようになります。

module: {
        rules: [
            { test: /\.ts$/, loader: 'ts-pipe-operator', enforce: 'pre' },
            { test: /\.ts$/, loader: 'ts-loader' },
            ...
        ]
 }

@garkinが指摘している

おそらく、TSサービスのNFRを作成して（またはすでに1つあるのでしょうか？）、ソースファイルとコンパイラにフィードされるトランスパイルされた結果の間に適用される累積ソースマップをサポートする場合、このプラグインや他のプラグインは、コミュニティの残りの部分、そして最も重要なこととして、コアチームが対処するための複雑さを追加することなく。

また、＃13940がこれにどの程度関連しているかはわかりませんが、より複雑なプラグインに向けた良いスタートとなるようです。 ただし、ミニマルな（プレ）トランスパイラーはほとんどの場合プロジェクトコンテキストを必要としないため、ソースマップアプローチはさらに単純な代替手段であるように思われます。生のテキストを記述し、制御フローがトランスパイルされた部分の特定のI / Oタイプを暗示できるように書き直します。

最後になりましたが、この種のプラグインに関する_official_スレッド（ある場合）を誰かに教えてもらえますか？

私は、新しい提案を導入する穏やかな方法に本当に感謝し、Flow + BabelやPost-CSSの特別なプラグインオリンピックよりもモノリシックなTypescriptとLessCSSツールをはるかに好むと言う必要があります。

これは、カスタマイズ性と、肥大化した断片化のコストと専門分野で新しい機能を取得する速度です。

パイプオペレーターは、機能の世界への入り口の薬のようなもので、奇妙なことを言わせてほしいと思います。

したがって、＃14419があり、すでにいくつかの有用な実用的な意味があります。 それらをts-loaderと統合するのは難しいことではありません。

tsconfig.jsonトランスフォーマーの統合（および、カスタマイズされたtscだけでなく、Language Service API）＃14654は_短期的に_拒否されました。

11976は、リンティング専用ツールのように見える言語サービスプラグインについて議論しています。

トランスフォーマーへのこれらのプラグインの拡張を提案する16607。

@PublicParadiseまたはlodashのflowまたはRambdaのpipeますか？

とにかく、これはTSでサポートされているのを見るのはとても素晴らしいでしょう。 JSがサポートする機能パターン（特にTSの型推論）は気に入っていますが、一部のパターンはあまり読みやすくありません。 RxJSやIxJSのような大きなTSライブラリは、プロトタイプの拡張/継承よりもポイントフリーの機能構成に移行しているため、これは非常に大きなものになります。これにより、ツリーの揺れとカスタム演算子のサポートが大幅に向上します。

@felixfbeckerあなたはpipe意味しますか？ もう一度試す必要がありますが、歴史的には、ramdaはJSファーストのライブラリであり、非常に動的で入力が難しく（lodashのように）、TSが関数の戻り値から推測するのに多くの問題を抱えていたという事実が加わっています（最近修正されましたが、確かではありません）
lodashは設計が不十分で、1つの大きな名前空間に可変関数と不変関数が混在しているため、使用しません。

関数とチェーンが非常にクレイジーでない場合、実際には適切に機能します。

https://github.com/DefinitelyTyped/DefinitelyTyped/blob/b67c928904f03d0911c99ab938b14bc2e59cad40/types/lodash/index.d.ts#L7819 -L7855

あなたの関数とチェーンが超クレイジーでなければ、それは実際にうまく機能します

そこで「超クレイジーではない」と認定させてください。関数にジェネリックが含まれている場合（https://github.com/types/npm-ramda/issues/86を参照）、たとえばR.pipe(R.identity)ます。

また、明確にしましょう。提案はステージ1です。コアチームは、ステージ3の前に物事を紹介することにさらに恥ずかしがり屋になっています。デコレータは例の一部です。 それらが_experimental_としてマークされていたとしても、私たちは皆先に進んでそのフラグを有効にし、それらを使用してすべての本番コードを作成しました。 提案は今や跳ね返り、構文とセマンティクスにいくつかの根本的な重大な変更があります。これは、コアチームをタイトな状況に置くコードをリファクタリングする必要があることを意味します。誰もがそれをリリースした日に構文が壊れているか、レガシーのものを保持している場合、コンパイラの他の変更により2つの構文のサポートが困難になる可能性があり、最終的には古いものを削除したいのですが、いつ.. .💥💥

したがって、このような標準ベースの機能を使用するための最善の方法は、TypeScriptのサポートやサポートの欠如についてここで議論することではなく、フレンドリーなローカルTC39担当者を見つけて、この機能があなたにとって本当に重要であり、参加することを提唱することです。 GitHubで上記にリンクされている提案の会話。 セマンティクスがより早く解決され、ステージ3に到達するのがより速くなると、私たち全員がより早く素晴らしいものを手に入れることができます！

rxjsにlettable演算子が追加されたので、これはTypescriptにあるさらに素晴らしい機能になります。
https://github.com/ReactiveX/rxjs/blob/master/doc/lettable-operators.md

TSチームの誰かに、このリクエストに光を当ててもらうことはできますか？

持っている、彼らはそれにES NextとSuggestionタグを付けました...私はあなたに章を引用し、ESNextの提案についてコメントした他の場所とそれらをいつどのように実装するかを説明することができます...

彼らからのコメントは何も変わりません。 彼らは舞台裏で密かに取り組んでいて、コミュニティでそれが生まれるのを待っていると思いますか？ 追加するものがない場合、彼らは問題について入力しないことがよくあります...すでに言われていることに追加するものはありません。

この時点で、言語を拡張するプラグインがあると非常に便利だと思います。 言語のコアの一部にならない機能を追加すると、これらのプラグインの一部になります。

@aminpaksすぐにバベルの塔につながる可能性があるため、このアイデアはあまり好きではありません（バベルの塔のように、優れたトランスパイラーのバベルの塔ではありません😀）

プラグインはタイプレベルの動作を意味するため、プログラムの意味を理解することは困難になり、ソースレベルの依存関係を処理するには、TypeScriptには現在欠けている複雑で非常に便利な機能が多数必要になります。

これを可能な限り可能にするのと同じくらい、TSが新しい機能を実装し、標準に準拠するために、より控えめなアプローチを取っていることをうれしく思います。 このスタンスは、標準からの逸脱を深く気にかけているが、ブラウザーベンダー/ JSエンジンの採用に先んじて（ただし、必ずしも標準化に先んじて）トランスパイルが提供する高度な機能を楽しんでいる私のような人々にとって、TSを全体的に魅力的にします。 それは微妙なバランスを取る行為です。

個人的には、bind-operatorを犠牲にしてパイプライン演算子を支持することはありません。 それは本当に読みやすさに帰着します。

与えられた：

function* where<T>(items: Iterable<T>, predicate: (item:T)=>boolean){
  for (let item of items){
    if(predicate(item)) yield item;
  }
}

bind-op：

[1,2,3]::where(x=>x>2)

パイプライン操作：

[1,2,3]|>(_)=>where(_,x=>x>2)

ts-teamは、ステージ3まで気にしないで正しいです。 その場合でも、ステージ3の提案は取り消すことができます（SIMDなど）。 プラグインを持てないのは残念ですが、「リスク」は個々の開発者に渡されます。 プラグインのユースケースは他にもたくさんあります。特に、typescriptを含む.vueファイルなどをサポートする場合

@MeirionHughes同意します。 砂糖をまったく使わないよりもパイプライン演算子を使いたいのですが、関数が自動カレーされ、それを利用してライブラリが構築されている言語に触発されています。 また、パイプラインメソッドがパイプライン値のメンバーではないことも前提としています。

だからあなたは

function where<T>(predicate: (item: T) => boolean): (items: Itererable<T>) => Itererable<T> {
  return function* () {
    for (const item of items) if (predicate(item)) yield item;
  };
}

function select<T, R>(projection: (item: T) => R): (items: Itererable<T>) => Itererable<R> {
  return function* () {
    for (const item of items) yield projection(item);
  };
}

そして、あなたは書くでしょう

[1, 2, 3] |> where(x => x > 2) |> select(x => x ** 2);

ただし、JavaScriptは関数を自動カリー化しないため、自動カリー化できないため、カリー化を念頭に置いて設計されたライブラリでのみうまく機能するようです。

私はこれについて誤解されているかもしれません、私は提案についてあまり最新ではありません。

次に、デフォルトでカレーされたutil関数を提供する新しいライブラリが新しい標準になる可能性があります：p

@AlexGalaysこれが合格すればそうなると思います。 JavaScriptをOCamlに変えることは破壊的な陰謀の一部でない限り、すべてが順調です。

@MeirionHughesあなたの例は正しくありません。 where関数はthisをまったく使用しないため、バインド演算子は機能しません。 バインド演算子には、型の安全性に関する多くの未解決の質問もあります。 where thisは、クラスメソッドのようにthisを使用する意味は何ですか？ はいの場合、私有財産の変更は突然、重大な変更となり、私有財産の目的を完全に無効にします。
また、構文が読みにくいと述べていますが、たとえば、bind-operatorの例では親を省略し、パイプラインの例では不要な親を追加しています。 もちろん、パイプライン演算子は、バインディング用に記述された関数ではまったく機能しませんが、rxjs演算子、ramda、lodash / fpなどのカリー化された関数ではうまく機能します。

@aluanhaddadすべてのfpライブラリに加えて、RxJSは、プロトタイプの演算子（主にツリーの揺れやジェネリック型の安全性に関して多くの問題がある）からカレー関数としての演算子に移行した、広く使用されているライブラリの例です。 ほとんどのライブラリは、おそらく現在その方法を選択していません。なぜなら、適切な構文がないためです。

@felixfbeckerはその通りであり、パイプされる結果の関数をネストする@aluanhaddadの例は、私の考えを完全に変えました。

パイプラインのサポートを少し早く取得するために、カスタムトランスフォーマーについて考えた、または実装している人はいますか？ 見た目からは、パイプライン部分自体にバベルトランスパイルを追加するだけのカスタムトランスフォーマーを介して実行できます。 その後、 https ： ます。

それは可能ですか？ TypeScriptsツールのようなものを機能させながら、カスタム変換を使用してBabelでサポートされているサポートされている構文を使用しますか？

多分？ 0-2の提案のみを扱うプリセットがあります： https：//github.com/cevek/ttypescript#visual -studio-codeを使用すると、問題が解決する場合があります。

@MeirionHughesお役に立ててうれしいです❤️。
これで、任意のプロトタイプのメソッドをカリー化された関数に変換できるように、＃6606が必要になります。

TypeScriptは現在、バベル変換です。TypeScriptがパスする前に、パイプラインで脱糖をシーケンスする方法があるはずです。 ただし、言語サーバーでそれをどのように機能させるかはわかりません。

TS＃22816のセルフホスト実装を追加しました

パイプラインオペレーターを推進している人の一人として、私はあなたにお願いします：それがさらに進むまで、TypeScriptでこれを実装しないでください。 根本的に相互に互換性のない2つの潜在的な提案についてはまだ議論中です。そのため、TypeScriptは、これを実装するのが早すぎると、世界に苦痛を求めています。

この提案に興味がある場合は、こちらのリポジトリをご覧になり、参加してください： //github.com/tc39/proposal-pipeline-operator/フィードバックをお待ちしています。 また、さまざまな提案に対応するBabelプラグインに取り組んでいるため、（TypeScript以外の）プロジェクトでそれらを試す機会があります。

しかし、この提案はまだTypeScriptのようなものに着手する準備ができていません。

私たちは間違いなくこれをマージしていません。

https://github.com/babel/babel-eslintのように、Babelでサポートされている機能を引き続き使用し、TypeScriptでサポートされていない機能が削除された後にタイプチェックを機能させることができますか？

@masaeeduはい！ この

@MeirionHughesの部分適用提案により、より簡単になります。

[1,2,3] |> where(?, x=>x>2)

@bernatmv ：fwiwそれに近いものが今日機能します。

@ tycho01しかし、TypeScriptではなく、2.8のタイピングを取得するまでは： https ：

@jeremejevs @bernatmv実際には、 R.__はnpm- ramdaのcodegenを使用して入力されています。 2.8を使用するより良い方法を歓迎します！

私はJavascriptとTypeScript（2週間）に少し慣れていないので、もっと簡単な解決策があれば許してください。 しかし、以下はパイプラインオペレーターがいない場合に私が思いついたものです。 私はもともと、2、3、4などのタイプパラメーターで機能するpipe複数のオーバーロードを試してみましたが、C＃のようにTypeScriptオーバーロード解決を機能させる方法を理解できませんでした。 さまざまな関数pipe1<A,B> 、 pipe2<A,B,C> 、およびpipe3<A,B,C,D>を使用できますが、引数の数に基づいて関数名を選択する必要があるため、これを操作するのは困難です。欲しかった。 私が以下に提案したものよりも単純なタイプセーフな解決策はありますか？ 無制限のパラメーターを受け入れることができる再帰型定義はありますか？ 条件タイプを適切に使用していますか？

type LastOf<
    A,
    B=never,
    C=never,
    D=never,
    E=never,
    F=never,
    G=never,
    H=never,
    I=never,
    J=never> =
    [B] extends [never] ? A :
    [C] extends [never] ? B :
    [D] extends [never] ? C :
    [E] extends [never] ? D :
    [F] extends [never] ? E :
    [G] extends [never] ? F :
    [H] extends [never] ? G :
    [I] extends [never] ? H :
    [J] extends [never] ? I :
    J;

export function pipe<A, B, C=never, D=never, E=never, F=never, G=never, H=never, I=never, J=never>(
    a: A,
    mapA: (a: A) => B,
    mapB?: (b: B) => C,
    mapC?: (c: C) => D,
    mapD?: (d: D) => E,
    mapE?: (e: E) => F,
    mapF?: (f: F) => G,
    mapG?: (g: G) => H,
    mapH?: (h: H) => I,
    mapI?: (i: I) => J
): LastOf<A, B, C, D, E, F, G, H, I, J> {
    if (mapB === undefined) {
        return mapA(a) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapC === undefined) {
        return mapB(mapA(a)) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapD === undefined) {
        return mapC(mapB(mapA(a))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapE === undefined) {
        return mapD(mapC(mapB(mapA(a)))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapF === undefined) {
        return mapE(mapD(mapC(mapB(mapA(a))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapG === undefined) {
        return mapF(mapE(mapD(mapC(mapB(mapA(a)))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapH === undefined) {
        return mapG(mapF(mapE(mapD(mapC(mapB(mapA(a))))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    if (mapI === undefined) {
        return mapH(mapG(mapF(mapE(mapD(mapC(mapB(mapA(a)))))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
    }
    return mapI(mapH(mapG(mapF(mapE(mapD(mapC(mapB(mapA(a))))))))) as LastOf<A, B, C, D, E, F, G, H, I, J>;
}

test("map once", () => {
    const result = pipe(
        2,
        i => i * 10);
    expect(result).toBe(20);
});

test("map twice", () => {
    const result = pipe(
        2,
        i => i * 10,
        i => `the answer is ${i}`);
    expect(result).toBe('the answer is 20');
});

test("map three times", () => {
    const result = pipe(
        2,
        i => i * 10,
        i => -i,
        i => ({ a: i, b: -i }));
    expect(result).toEqual({ a: -20, b: 20 });
});

lodash / fpの_.flowはこれをすでに入力していると思いましたか？

2018年5月9日水曜日、22：19 jmagaram、 notifications @ github.comは次のように書いています。

私はJavascriptとTypeScriptに少し慣れていません（2週間）のでご容赦ください
もっと簡単な解決策があれば私に。 しかし、以下は私が思いついたものです
パイプラインオペレーターがいない場合。 私はもともと持ってみました
2、3、4などのタイプで機能したパイプの複数の過負荷
パラメータが、TypeScriptオーバーロードを取得する方法を理解できませんでした
C＃と同じように機能する解像度。 私たちはさまざまな機能を持つことができます
pipe1 、pipe2 、pipe3ですが、これは難しいでしょう数に基づいて関数名を選択する必要があるため、あなたが望んでいた議論。
を受け入れることができる再帰型定義はありますかパラメータの無制限のアンバー？

タイプLastOf = [B]は[決して]拡張しませんか？
B：[D]は[決して]拡張しませんか？
D：[F]は[決して]拡張しませんか？

機能パイプ（ a：A、mapA：（a：A）=> B、mapB？:（ b：B）=> C、mapC？:（ c：C）=> D、mapD？:（ d：D）=> E、mapE？:（ e：E）=> F）：LastOf { const b = mapA（a）;スイッチ（mapB）{未定義の場合：bをLastOfとして返します; ディフォルト： {const c = mapB（b）;スイッチ（mapC）{未定義の場合：cをLastOfとして返します; ディフォルト： {const d = mapC（c）;スイッチ（mapD）{未定義の場合：dをLastOfとして返します; ディフォルト： {const e = mapD（d）;スイッチ（mapE）{未定義の場合：eをLastOfとして返します;デフォルト：mapE（e）をLastOfとして返します; }}}}}}}}

test（ "map once"、（）=> {
const result = pipe（
2、
i => i * 10）;
expect（result）.toBe（20）;
}）;

test（ "マップを2回"、（）=> {
const result = pipe（
2、
i => i * 10
i => the answer is ${i} ）;
expect（result）.toBe（ '答えは20'）;
}）;

test（ "map three times"、（）=> {
const result = pipe（
2、
i => i * 10
i => -i、
i =>（{a：i、b：-i}））;
expect（result）.toEqual（{a：-20、b：20}）;
}）;

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment-387878691 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZQTLm6LrWe5KVx4aGBFUd4yRUHkkrZks5tw11cgaJpZM4OzVEg
。

lodashを見たところ、あなたは正しいです-flow関数は多くのパラメーターを受け入れ、強く型付けされています。 Iitは純粋なTypeScriptで行われているようには見えません。 それらはすべてのオーバーロードに型定義ファイルを使用します。 TypeScriptですべてをやろうとするよりも、これが良いのか悪いのかはわかりません。

@jmagaram all TSは、一般的に推論により簡単になりますが、機能する場合は機能します。

@jmagaramやや単純な純粋なtypescriptの代替は、次のようになります。

interface IPipe<T> {
    readonly value: () => T;
    chain<R>(fn: (x: T) => R): IPipe<R>;
}

function pipe<T>(val: T): IPipe<T> {
    return {
        chain: fn => pipe(fn(val)),
        value: () => val
    };
}

使用法はまだかなりクリーンで強く型付けされています。

pipe(["Hello", "There"])
    .chain(map(x => `${x}!`))
    .chain(xs => {
        ...
    })
    .value()

カスタム演算子を追加できることを本当に感謝しています。 F＃には、このための優れたアプローチがあります。

それまでの間、ラッピングなしのより簡単なアプローチを次に示します。

function pipe<T1>(first:T1):T1
function pipe<T1, T2>(first:T1, second:(a:T1) => T2):T2
function pipe<T1, T2, T3>(first:T1, second:(a:T1) => T2, third:(a:T2) => T3):T3
function pipe<T1, T2, T3, T4>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4):T4
function pipe<T1, T2, T3, T4, T5>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5):T5
function pipe<T1, T2, T3, T4, T5, T6>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6):T6
function pipe<T1, T2, T3, T4, T5, T6, T7>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6, seventh:(a:T6)=>T7):T7
function pipe<T1, T2, T3, T4, T5, T6, T7, T8>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6, seventh:(a:T6)=>T7, eigth:(a:T7)=>T8):T8
function pipe<T1, T2, T3, T4, T5, T6, T7, T8, T9>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6, seventh:(a:T6)=>T7, eigth:(a:T7)=>T8, ninth:(a:T8)=>T9):T9
function pipe<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10>(first:()=>T1, second:(a:T1)=>T2, third:(a:T2)=>T3, fourth:(a:T3)=>T4, fifth:(a:T4)=>T5, sixth:(a:T5)=>T6, seventh:(a:T6)=>T7, eigth:(a:T7)=>T8, ninth:(a:T8)=>T9, tenth:(a:T9)=>T10):T10
function pipe(first:any, ...args:Function[]):any {
    return (
        args && args.length 
        ? args.reduce(
            (result, next) => next(result),
            first instanceof Function ? first() : first
        )
        : first instanceof Function ? first() : first
    );
}

これは与える：

（詳細については、こちらを参照してください）

そうは言っても、 @ graingert +1あなたは正しいです：lodashはすでにこれを構成用に持っています（パイプではありません）：

const getUpperName = 
   _.flow(
      (p: Person) => `${p.FirstName} ${p.LastName}`,
      (s: string) => s.toUpper()
   )

または、代わりにObject.prototypeにパイプを追加することもできます。

Object.prototype.pipe = function<Self, Result>(this:Self, next:(value:Self) => Result):Result {
    return next(this)
}

これにより、代わりに次のことが可能になります。

（詳細については、こちらを参照してください）

これが他の人に役立つことを願っています！

それは--enable-pipeline-operatorコンパイルフラグの下でFirefoxに上陸しました。

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Pipeline_operator

倒れた英雄、バインド演算子::の黙祷は、邪悪な|>を支持して閉じられました😢

私は|>を好むので、それは見る人の目にあると思います：D

王に歓呼！

そしてここで私はそれがパイプの夢だと思った

パイプラインは、基本的にIdentityMonadの単純なユースケースです。 また、 pipeは通常逆にcomposeが、 pipelineはすぐに呼び出されるpipe似ています。

とにかく、Typescriptでこれを見るのを楽しみにしています。

パイプラインがあると便利ですが、コンパイラトランスフォーマーを介してカスタム演算子（名前に特殊な文字が含まれる可能性があり、最初のパラメーターが左側にある関数）を定義する機能を提供できると思います。 私と一緒にこれを試すことに興味がある人、またはこれに関する背景がありますか？

金、2018年8月10日には、午前2時53分ババクの[email protected]は書きました：

パイプラインは、基本的にIdentityMonadの単純なユースケースです。 また、
パイプは通常逆に構成されますが、パイプラインはパイプのようなものです
それはすぐに呼び出されます。

とにかく、Typescriptでこれを見るのを楽しみにしています。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment-411824741 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AFXUx5rwM9wVrpAkHK2BNYkyy74HtWU5ks5uPGkNgaJpZM4OzVEg
。

-

中置関数ftw

2018年8月9日木曜日、23：35 Ben Beattie-Hood、 notifications @ github.com
書きました：

パイプラインがあると便利ですが、それは可能だと思います
カスタム演算子（名前が
特別な文字を含み、その最初のパラメータは左側にあります）
コンパイラトランス。 私と一緒にこれを試すことに興味がある人、または持っている人
これに関するいくつかの背景？

金、2018年8月10日には、午前2時53分ババクの[email protected]は書きました：

パイプラインは、基本的にIdentityMonadの単純なユースケースです。 また、
パイプは通常逆に構成されますが、パイプラインはパイプのようなものです
それはすぐに呼び出されます。

とにかく、Typescriptでこれを見るのを楽しみにしています。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
<
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment -411824741
、
またはスレッドをミュートします
<
https://github.com/notifications/unsubscribe-auth/AFXUx5rwM9wVrpAkHK2BNYkyy74HtWU5ks5uPGkNgaJpZM4OzVEg

。

-

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/17718#issuecomment-411919587 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAZQTHHFbVY5uGCWl-La_P-HF7UN6xPsks5uPLk8gaJpZM4OzVEg
。

typescriptのインフィックス関数の考え方は、typescriptとほぼ同じくらい古いものです： https ：

多くの人がこれを本当に悪いことを望んでいることは知っていますが、TypeScriptは、ステージ3にない限り、余分な演算子を実装すべきではないと思います。状況は変わる可能性があり、もちろんいくつかの例外があります。

コミュニティがアイデアを探求し、人気を測定できるようにするためだけに、コンパイラトランスフォーマーとして試す価値があると思います。 これは他の関数型言語で明確に定義された機能であるため、探索するのは非常に安全かもしれません。

@BenBeattieHoodこれをbabelで実装している現在の提案を必ず確認してください。

それがどのように使われるかについて多くの考えが必要だと思います。 特に次のような入力に関して：

function where<T>(predicate: (x: T) => boolean) {
  return function* (items: Iterable<T>): Iterable<T> {
    for (const item of items) {
      if (predicate(item)) {
        yield item;
      }
    }
  };
}

[1, 2, 3] |> where(x=>x> 1)

現時点ではwhere(x => x > 1)([1,2,3])では、xが何であるかを推測できません。 上記は私が:: opが勝つことを望んでいた理由の1つです。なぜなら、（一見すると）typescriptがthisが何であるかを推測するのがはるかに簡単に見えるからです。

または、別の方法で見ることができます。リリースされた場合、TSが抱える推論の問題のいくつかが優先されます👍

スペックとバベルのニュースをフォローすると、スペックはまだ設定されていません。 2つの提案があります。 仕様が完成したときに、typescriptチームがサポートを追加すると確信しています

中置関数ftw

iircJSはこれらを「メソッド」と呼んでいます。

iircJSはこれらを「メソッド」と呼んでいます

@ tycho01あなたのコメントはおそらく頬の舌ですが、これらはまったく同じものではないと思います。 バイナリ関数をどこかからエクスポートして、2つの値にインフィックスで適用することはできません。 値を操作するすべての関数に関する知識は、直接プロパティとして、またはプロトタイプとして、値自体に移植する必要があります。 これは実際のシナリオではかなり不便です。

@BenBeattieHoodこれをbabelで実装している

Babelパーサーは、スマートパイプラインの提案をサポートするようになりました。

https://github.com/babel/babel/pull/8289

更新はありますか？

更新はありますか？

🤦‍♂️TypeScriptは、ステージ3に到達するまで提案を実装しません。パイプラインオペレーターは現在ステージ1であり、重大な問題があります。 その情報は、このスレッドで複数回提供されています。

深刻な問題の例をお願いしますか？

多分...

⚠警告：パイプライン構文の詳細は現在未解決です。 検討中の2つの競合する提案があります。

はい、それは私が深刻な問題だと考えていることです。

Waiting for TC39ステータスのすべてのスレッドは円ため、これをロックします。

ping！