おそらく、これがダウンレベルでどのように放出される可能性があるかについてのいくつかの例が必要になるでしょう（それが範囲内にある場合）。

@RyanCavanaugh 、私はいくつかの小さな放出例とタイピングのアイデアを追加しました。
とにかくそれは多かれ少なかれjsx機能であり、フォークに追加する必要があるので、これに取り組みたいと思いますが、typescriptコアに追加する場合はより良いです^^。

私は最近、この記事を通じてES7でこの機能を発見しました。 私は言わなければならない、それは非常に便利です！

TypeScriptでこれを見たいです！

これに関する更新はありますか？ React：smile：で使用すると非常に便利になるので、1.6でこれを見てみたいと思います。

記録のために@prabirshrestha 、現在master JSXのプロパティスプレッド演算子があります。

@DanielRosenwasser詳しく教えていただけますか？ これは、-jsxフラグを使用してマスターで機能することを意味しますか？ それは残りのプロパティを含みますか、それとも単にスプレッドプロパティを含み

申し訳ありませんが@mnpennerと@prabirshrestha 、はい、私はmasterを意味しました。 @RyanCavanaughは私よりもこれについて

JSXはspread_attributes_をサポートします（例： <TagName {...spreadedExpr} /> 。 同じトークンを共有し、ほぼ同等のセマンティクスを持つ以外は、ES6スプレッド演算子とは何の関係もありません。

私はReduxとReactの両方に非常に興味があります。これにより、状態での操作がはるかに簡単になります。 これが実装されるのを見たいです。

Rest / Spreadはステージ2で承認されましたhttps://github.com/tc39/tc39-notes/blob/master/es7/2015-07/july-30.md

これに対処する前に、提案がステージ3に到達するのを待ちたいと思います。

これはreactとreduxで非常に便利です。できるだけ早く実装してください:-)

これは、これを回避するために使用しているヘルパーモジュールです。 すべてのキーを左側に1回、右側に文字列として2回指定する必要があるため、理想的ではありませんが、これ以上の方法は考えられません。 どんなフィードバックでも歓迎します、私が逃したエッジの振る舞いがあると確信しています！

https://gist.github.com/tomduncalf/fbae862b123445c117cb

これはパッチを受け入れるものですか？ （ステージ3に到達するとマージされます）。もしそうなら、それをサポートするためにどこから変更を始めるべきかについての指針はありますか？

これは、私のチームが頻繁に使用する最後のES7 +機能であり、typescriptへの切り替えを妨げています。可能であれば、もっと早くしなければならないことは間違いありません。

ここでPRを検討します。 ただし、この機能の型システムの配線は簡単な作業ではありません。 あなたがこれを熟読することに興味があるなら、私はそれをインクリメンタルに保ち、構文解析から始め、次に放出し、次にタイプチェックをします。 質問がある場合は、 @ sandersnがお手伝いします。

Reduxでこれを使用することに興味がある人のためのメモ。 表記が便利だと思います。 しかし、私は実際には、 updeepライブラリを活用することで、それがなくても問題なく動作しています。 私はそれのためにいくつかの基本的なタイピングを作成しました、そしてそれはかなりうまくいきます。 updeepベースのストアとアクションを実装する単純なライブラリもあります。 誰かがこれに興味があるなら、私に連絡してください。

いずれにせよ、TSのスプレッド演算子の場合は：+1 ：。 ：笑顔：

@xogenyそのライブラリを見てみたいと思います。 ありがとう

@ cur3n4私はこれらのアイデアで遊んでいるリポジトリを持って最初はupdeepを利用した特別なモジュールを使用していましたが、その機能はまだライブラリにあります。 しかし、必要な型制約を維持するのが難しいと思ったので、使用をやめました。 TypescriptにJavaのsuperジェネリック型制約に沿った何かがあるとしたら、 updeep （およびlodashやramdaなどの他のいくつかのライブラリ）はより多くのタイプセーフになりました。

しかし、誤解しないでください。それでも、スプレッド演算子は本当に便利だと思います。 実際には、現在の型システムではどうしたらよいかわからない言語で、安全かつ簡潔に表現して実行できるようになります（つまり、外部ライブラリの正しい型制約を記述できるようになります）。 今のところ、私は安全のために簡潔さを犠牲にします（ updeepアプローチは簡潔さのために安全性を犠牲にしました）。

過去数か月間Babelを使用した後、私のプロジェクトをTSに変換し、これらすべてをやり直さなければなりませんでした。 これが実装されるのを見たいです！

：+1：

これを見たいです。

+1

機能が必要です、実装してください

+1

+1 Object.assign + JSXサポートよりもはるかに優れた構文

+1それは小道具を渡すためのreact開発に必要です（ var { checked, ...other } = this.props; 。 reactドキュメントを参照してください

それは反応開発のために持っている必要があります

正直に言うと、これは便利であり、必須ではありません。 提案はTC39でステージ2にあります。 TypeScriptチームは、ステージ3になるまで、TypeScriptで作成されていないものの実装を検討したくないことを明確にしています。「+ 1」の場所はTC39です。

@ kitsonk -react /などのフレームワークがドキュメントでこれらのタイプのものを具体的に呼び出す場合、適切な採用を期待することはできません。 人々はTypescriptを使い始め、これらすべての問題を見て、Babelに戻ります。 それが私がしたことです。

まあ、私たちはもっと広いトピックについて話していると思います。 ステージ3にないものを実装するブラウザベンダーはありません（個人的に気に入っている場合を除く）。 TC39は、Webの一部にある程度の組織化を図ろうとしています。 TypeScriptは、前に銃をジャンプすることによって、非常に噛まれてきました（モジュール、そしてそれ以降に引き起こされた混乱を見てください）。 私は、彼らが少なくとも、彼らが何をいつ実施しようとしているのかについて、いくつかのガイダンスと構造を導入しようとしていることを尊重します。 どの標準を使用すべきかについて他に提案はありますか？ 「Xフレームワークがドキュメントでそれを言及しているので」は良いものではないと思います。

react / etcのようなフレームワークは、ドキュメントでこれらのタイプのものを具体的に呼び出します

彼らはそれを単なる提案としてマークし、次にフープを飛び越えてそれを使用するようにBabel6を構成する方法を指示します。 私はむしろ、ドラフト仕様にのみある構文技術に依存するためのフレームワークを非難したいと思います。 個人的には、私たちDojoは、 Object.observe火傷を負いました。私は、Dojoのステージ3に到達する前に、テクノロジーに依存しようとすることを再び躊躇しています。

特定のパスは、TypeScriptのemitで構文の変換をサポートするだけではありません。 それに続く必要があるすべての型推論があります。 ドラフト仕様を見て理解しましたが、シンボルはどこに行きますか？ 列挙できないプロパティはどこに行きますか？ どちらの場合も、それらはエーテルに消えてしまうと思いますが、これにはバックグラウンドで実行する必要のあるあらゆる種類の型の分割とマージが行われるため、TypeScriptチームが「OK、延期しましょう」と言っていることを完全に理解できます。 TC39が本当にこれにタイヤを蹴るまでこれで」。

全体として、TSは今日非常によく取り上げられていると思います。 ES2015の機能が不足していることに不満を感じていた時期がありましたが（1.4〜1.5程度だと思います）、今日の時点でTSは標準にかなり追いついています。

もちろん、他の言語にうらやましい機能があることもあります。 たとえば、Babelは、「実験的な」ものを含め、ほとんどすべてのJS提案を提供します。 個人的には、この問題と関数バインド演算子も楽しみにしています。

しかし同時に、TSチームはバベルよりも互換性を真剣に受け止めていることを認めなければなりません。 彼らは、リリース間でコードのセマンティクスを変更したり、単に機能を削除したりすることを望んでいません。これは、Babelが行うことです。 いくつかの（企業？）プロジェクトにとって、それは重要です。

また、MSは、ドロップされる可能性のある機能に多くのリソースを投資したくないことも理解できます。 Object.observe大失敗が思い浮かびます。 実際、彼らはこれについてのPRを検討すると言っていました。例えば：

以前は、一部の機能が実験的なコンパイラスイッチ（非同期など）の背後に早期に追加されていました。つまり、オプトインして、機能が変更されるか、将来のリリースで削除される可能性があることを確認する必要がありました。 たぶん、それは最も人気のあるリクエストに対して再び行うことができますか？

ここに簡単なメモがあります。 主に下位互換性の懸念から、ステージ0-1で提案されたES機能の採用はかなり遅れています。 私たちはTC39の会議での議論を綿密に追跡し、会議に直接参加するか、会議の前に提案の準備に参加します。 そして、機能を組み込むときに、それらに依存しているユーザーにとってそれが何を意味するのかを知りたいと思います。
TC39プロセスのドキュメントを見ると、ステージ1の機能は、受け入れ後の「メジャー」な変更を期待できます。 これは、クラス、モジュール、イテレーター、およびほとんどすべての重要なES6機能の場合でした。
私のユーザーの帽子をかぶって、構文への変更を壊すことは応答するのに機械的である可能性がありますが、セマンティクスへの変更を壊すことはキャッチして修正するのが非常に難しい場合があります。 これは、これらの機能のいずれかを使用するチーム、および/またはツールの新しいバージョンを採用するためのブロッカーに莫大なコストがかかる可能性があります。 可能な場合はそれを最小限に抑えたいと思います。 そのため、ステージ3に到達したときにデフォルトで機能を有効にし、その前に実験的なフラグ（デコレータなど）を使用するポリシーを採用しました。
そうは言っても、オブジェクトプロパティのスプレッドと残りはロードマップにあり、将来のリリースでそれらに取り組む予定です。

たぶん、babelで行われているように、いくつかのサードパーティの拡張機能を挿入する機能をコンパイラに追加することを検討する価値がありますか？

別の考え：typescriptソースの前処理（Babelを使用）のサポートはどうですか？

Babel（または任意のライブラリ）にオブジェクトスプレッドをObject.assign呼び出しに拡張させることができれば、それで十分に機能する可能性がありますか？ うまくいけば、Babelに実装されている他の実験的な機能にも一般化できるでしょう。

@ kitsonk-より広いトピックは絶対に、

。 TypeScriptは、前に銃をジャンプすることによって、非常に噛まれてきました（モジュール、そしてそれ以降に引き起こされた混乱を見てください）。

彼らは立ち去り、コミュニティからの何も使用せずに.NETをミラーリングする独自の実装を行いました。それは彼ら自身の責任です。

彼らが何をいつ実行しようとしているのかについて、いくつかのガイダンスと構造を置きます

デコレータ（ステージ1）、クラスプロパティ（ステージ1）などを実装します。

「Xフレームワークがドキュメントでそれを言及しているので」は良いものではないと思います。

冗談でしょ？ reactは最も人気のあるフレームワークであり、しばらくの間そのようにとどまると予測されています。 それをサポートしないことは、養子縁組を本当に傷つけます。

TypeScriptはBabelに追いつくことがたくさんあり、次のような多くの課題があります。既存のアプリで使用を開始するのは非常に難しい、A2のbabelからtypescriptへの移行は悪夢です！、分離されたプラグインの欠如ノードでの作業が非常に困難になります。

冗談でしょ？ reactは最も人気のあるフレームワークであり、しばらくの間そのようにとどまると予測されています。 それをサポートしないことは、養子縁組を本当に傷つけます。

私はReactをとても尊敬していますが、冗談ではありません。 それは町で唯一のゲームではありません、そしてそれは確かに大きな誇大宣伝曲線上にあります。 6か月前はReact + Fluxでしたが、現在はReact + Reduxがその日のフレーバーです。 1年前、AngularとPolymer。 2年前はバックボーンとエンバーでした。 6年前は、Dojo、MooTools、jQuery、gwt、ExtJSなどでした...

ここでフレームワーク戦争を開始しないでください：exclamation：
{..., }構文は、フレームワークに関係なく、そのままでも非常にハンサムです。

彼らは立ち去り、コミュニティからの何も使用せずに.NETをミラーリングする独自の実装を行いました。それは彼ら自身の責任です。

@amcdnl正確には何を指しているのですか？ モジュールを名前空間の問題と呼んでいると思いますが、これは.NETとは関係がなく、TypeScriptのモジュールの主な問題点の1つでもありません。

これがtypescriptノードに含まれるための+ 1jsはそれを実験的にサポートしています

typescript = {... typescript、object_spread}; // はい、お願いします。

残念ながら、これには動きがありません。これがすぐにステージ3に到達することを本当に望んでいます。 可能であれば、VSCodeでの構文エラーの強調表示を強制終了します

サルサがゲームに何かを変えるのだろうか？

TSは、リソースが限られている、ユーザーを重大な変更から保護するなど、不安定な機能を早期に実装することを望んでいないことを理解しています。

しかし、SalsaがVS CodeのデフォルトのJSエンジンになったことで、新しいJS構文（少なくとも構文だけで、完全なTSタイピングではない）へのプレッシャーが高まるでしょう。 特にバベルの人気を考えると。

Salsaは、TSよりも幅広い構文をより速く受け入れることができるようになりますか？

+1

これは2.0ではなく2.1になりますか？ ：泣く：
https://github.com/Microsoft/TypeScript/wiki/Roadmap#21

2.0がすでにどれだけ大きいかを考えると、私はそれほど驚いていません。

リリースは6〜8週間離しておくようにしています。 そのため、何が入るかが制限されます。現在、エミッターのリファクタリングを行っており、完了するとこの機能を追加できるようになります。

それで、これは修正されましたか？

...スプレッド属性のスタンドアロンヘルパー関数
https://github.com/Microsoft/TypeScript/releases/tag/v1.8.10

まだ「物件再編パターン期待」が出ているので

ではない正確に。 この修正は、特にJSXスプレッド属性用です。

const props = { foo: "bar" };
return <SomeComponent {...props} />;

これは、React v15がTypeScriptのJSXコンパイラが依存していた文書化されていない内部関数を削除する前に、すでに機能していました。 おっと😃

オブジェクトスプレッドは別の提案であり、明らかに類似した構文を使用しています（Facebookのエンジニアによって提案され、JSXの同等のものに触発された可能性もありますが、確かではありません）。

{...props}はまだ機能していないので、TypeScriptを使用してそれに似たものをどのように実現しますか？

{... props}はまだ機能していないので、TypeScriptを使用してそれに似たものをどのように実現しますか

xtend使用してください： https ：//www.npmjs.com/package/xtendそれは素晴らしいタイピングを持っています： //github.com/typed-typings/npm-xtend （ @blakeembrey ：rose :)ありがとう交差型へ

または、ライブラリをまったく使用しないでください。

const newProps = Object.assign({} /*new object*/, props /* add all attributes of props */, {
   // add additional props
  bar: "baz"
});

少し冗長ですが、ES2015にネイティブであるため、そのためのポリフィルを既に持っている場合は、堅実です。

この演算子は、プロジェクトでtypescriptの代わりにbabelを使用することにした主な理由の1つです。

オブジェクトを不変に処理するためのゲームを完全に変更します。

別の方法として、babelでできるようにカスタム変換をTSCにプラグインできるようにする計画はありますか？ たぶん同じAPIに基づいていても、それは素晴らしいことであり、このような問題を解決するでしょう。

別の方法として、babelでできるようにカスタム変換をTSCにプラグインできるようにする計画はありますか

@Niondirはい。 [Transforms]タグを検索するだけです。 これらは、TypeScriptコンパイラへの適切な非同期/待機/ジェネレータのトランスパイルを取得するために必要です：rose：

少し検索した後、これを参照していますか？ https://github.com/Microsoft/TypeScript/wiki/Using-the-Compiler-API

そのAPIのオブジェクトスプレッドに関連するものは何も見つかりません。 たぶん、コンパイラAPIに基づいてこの問題を解決するのは素敵な小さなプロジェクトでしょう:)

@Niondir私の元のメッセージでより良いヘルプを提供しなかったことをお詫びします。 私はhttps://github.com/Microsoft/TypeScript/issues/5595 <について話しているので、ESNext構文にプラグ可能なemitが許可されます。 TypeScriptは、コードを_semantic_型システムで理解する必要があるため、Babelよりも少し複雑です。そのため、オブジェクトの拡散作業は、おそらくTypeScriptチームから行う必要があります。

プラグインベースのエミッターがあると、これが簡単になります。 はい、コンパイラAPIを使用します（または、プラグインシステムがセマンティック/スキャナーロジック用に公開されるまで、最初はコンパイラをfork可能性があります）

これは別の問題の質問かもしれませんが、「allow-experimental」オプションを追加して、TypeScriptに将来のことを許可させることはできませんか？ たとえば、スプレッド演算子と出力をそのまま許可します。 後でバベルで処理できます。

これは私が取り組んでいるいくつかのプロジェクトにとって必須の機能であり、このような重要なものなしでは移行できません。 できれば最高です。

最終的にどのように出荷するかはわかりませんが、オブジェクトリテラルのレスト/スプレッドとデストラクチャリングの作業を開始しました。 現在の計画では、排出に__assignポリフィルを使用する予定です。

これは私が過去3か月で聞いた最高のニュースです！

残念ながら、これをジェネリックスで機能させることは、多くの作業であることがわかりました。 次のようなコードを適切にサポートする必要があります。

function addId<T>(t: T): {...T, id: number} {
    return { ...t, id: 1 };
}

ご覧のとおり、 addIdは、新しい種類の型、つまりスプレッド演算子を含むオブジェクト型を返します。

いくつかの議論の後、2.1まで延期し、これをもう一度検討することにしました。 今、2.0の機能を実行することに集中する必要があります。

私の無知を許してください...しかし、それはaddIdように感じますその場合T & { id: number }を返すことができますか？ それとも、それが最適なソリューションになるのを妨げる共用体タイプの癖がありますか？

Tに何でも渡すことができるので、実際にはTをチェックする必要があるという意味だと思います。

addId<boolean>(true);
addId<number>(5);

バベルはそのような声明を黙って無視しますlet a = { ...true }しかし私はそれらが有効であるべきではないと思います

T & { id: number }はありません。 Tにidプロパティがある場合、オーバーライドされるためです。

一方、交差、結果のidタイプは、 Tのidタイプとnumberの交差になります。

つまり、 @ sandersnが言っているのは、別の型演算子が必要だということです。

ここでより良いタイピングソリューションの恩恵を受けることは間違いありませんが、 Object.assignすでに存在し、出力タイプとして交差点を素朴に使用しています。 ストップギャップの尺度として、残りの演算子がObject.assignまったく同じことを実行できないのはなぜですか？

不足している機能に関する多くの懸念が緩和され、代わりにすでにObject.assign使用されているため、望ましくない動作が発生することはありません。

これがサポートされていないことに実際に非常に驚いていました。

私たちがこれを手に入れるとすぐに、より楽しいものになります。 反応でうまく機能します！

入力しなくても嬉しいです

@ 2426021684合理的に聞こえるかもしれませんが、その影響を考慮してください。 入力されていない場合、つまりanyとして入力されている場合、構文を使用すると、式のリーフにanyが浸透します。

@aluanhaddadこれはObject.assignと同じになります。これは、選択の余地がないため、誰もが使用しなければならない回避策です（上記のJabXの投稿を参照）。

近いうちに@JabXの提案を実装することを検討してください。 この提案は、名前を除いてすべてステージ3であり、標準の一部になることは間違いなくあり、非常に明確で単純なセマンティクスを備えています。 プロパティスプレッドの構文サポートとObject.assign単純なタイピングを導入することは、「正しい」実装を待つ間、非常に役立つ一時的なギャップになります。 完璧を善の敵にしないでください。

https://facebook.github.io/react/warnings/unknown-prop.htmlで見ることができるように、残りのプロパティはReact15.2で非常に重要です

const divProps = Object.assign({}, props)
delete divProps.layout

特にコンポーネントの小道具の量が多い場合は、非常に醜いです

もう待つことができない人のために、ここに回避策があります：

function steal(result: any, data: any): any {
    for (var key in data) {
        if (value.hasOwnProperty(key)) {
            result[key] = data[key];
        }
    }
    return result;
}

export class SameAs<a> {
    constructor(public result: a) { }
    public and<b>(value: b): SameAs<a & b> {
        return new SameAs<a & b>(steal(this.result, value));
    }
}
export function sameAs<a>(value: a): SameAs<a> {
    return new SameAs(steal({}, value));
}

// example of use:

const mixture = sameAs(one).and(anotherOne).and(yetAnotherOne).result; // <-- ta-da!

この投稿は無視してください。より良い実装については以下を参照してください

これが私が貧弱な（typescript）コーダーの破壊操作のために思いついたものです：

declare interface ObjectConstructor {
  destruct<T extends Object>(data: T, props: any): T;
  destruct<T extends Object>(data: T, ...propNames: string[]): T;
}

function destruct<T extends Object>(data: T, ...removals: string[]) {
  const rest = <T>{};

  const keys = removals.length === 1 && typeof removals[0] === 'object' ?
    Object.getOwnPropertyNames(removals[0]) :
    <string[]>removals;

  Object
    .getOwnPropertyNames(data)
    .filter(x => keys.indexOf(x) < 0)
    .forEach(x => {
      (<any>rest)[x] = (<any>data)[x];
    });

  return rest;
}

Object.destruct = destruct;

// Usage example:

const srcObj = { A: 'a', B: 'b', C: 'c' };
// destruct using an object template
const onlyC = Object.destruct(srcObj, { A: null, B: null });
// destruct using property names
const onlyA = Object.destruct(srcObj, 'B', 'C');

オブジェクトレイアウトを使用することの明らかな利点は、レイアウトを入力でき、少なくとも何かをリファクタリングした場合に型の競合が発生することです。

更新（これも無視してください。さらに良い方法については以下を参照してください）

私はこれを（実際の環境でいじった後）作り直し、関数を操作するのがはるかに簡単なものを思いついた。

function deconstruct<TResult, TData>(
  result: TResult,
  data: TData,
  onHit: (result: TResult, data: TData, x: string) => void,
  onMiss: (result: TResult, data: TData, x: string) => void,
  propNames: string[]
  ) {

  Object
    .getOwnPropertyNames(data)
    .forEach(x => {
      if (propNames.indexOf(x) < 0) {
        if (onMiss != null) {
          onMiss(result, data, x);
        }
      }
      else {
        if (onHit != null) {
          onHit(result, data, x);
        }
      }
    });

  return result;
}

// shallow clone data and create a destructuring array of objects
// i.e., const [ myProps, rest] = destruct(obj, 'propA', 'propB');
function destruct<T>(data: T, ...propNames: string[]) {
  return deconstruct(
    [ <T>{}, <T>{} ],
    data,
    (r, d, x) => (<any>r[0])[x] = (<any>d)[x],
    (r, d, x) => (<any>r[1])[x] = (<any>d)[x],
    propNames
  );
}

// shallow clone data and create a destructuring array of properties
// i.e., const [ propA, propB, rest] = destructProps(obj, 'propA', 'propB');
function destructProps(data: any, ...propNames: string[]) {
  return deconstruct(
    [ <any>{} ],
    data,
    (r, d, x) => r.splice(r.length - 1, 0, d[x]),
    (r, d, x) => r[r.length - 1][x] = d[x],
    propNames
  );
}

// shallow clone data and remove provided props
// i.e., const excluded = omit(obj, 'excludeA', 'excludeB');
function omit<T>(data: T, ...propNames: string[]) {
  return deconstruct(
    <T>{},
    data,
    null,
    (r, d, x) => (<any>r)[x] = (<any>d)[x],
    propNames
  );
}

これらの関数を入力すると、作業がはるかに簡単になります。 私は特にReactでこれらを使用しているので、既知の小道具に強いタイピングを行うと非常に便利です。 これらの関数を使用する追加のコードがあり、reactに特に便利です。

const [ props, restProps ] = destruct(omit(this.props, 'key', 'ref'), 'id', 'text');

この場合、 propsはthis.propsと同じように入力されますが、（現在restProps ）転送用の小道具は含まれていません。

IMO、この問題のタイプセーフではない回避策を投稿しても、あまり得られません。

同意しました。現在、よりタイプセーフなバージョンに取り組んでいます。

これで別の刺し傷：

主なオブジェクトの拡張：

declare interface ObjectConstructor {
    rest<TData, TProps>(data: TData, propsCreator: (x: TData) => TProps, ...omits: string[]): { rest: TData, props: TProps };
}

function rest<TData, TProps>(data: TData, propsCreator: (x: TData) => TProps, ...omits: string[]) {
  const rest = <TData>{};
  const props = <TProps>propsCreator.apply(this, [ data ]);

  Object
    .getOwnPropertyNames(data)
    .filter(x => props.hasOwnProperty(x) === false && omits.indexOf(x) < 0)
    .forEach(x => {
      (<any>rest)[x] = (<any>data)[x];
    });

  return {
    rest,
    props,
  };
}

Object.rest = rest;

React固有の拡張機能：

declare module React {
  interface Component<P, S> {
    restProps<T>(propsCreator: (x: P) => T, ...omits: string[]): { rest: P, props: T };
  }
}

function restProps<P, S, T>(propsCreator: (x: P) => T, ...omits: string[]) {
  return Object.rest((<React.Component<P, S>>this).props, propsCreator, ...omits.concat('key', 'ref'));
}

React.Component.prototype.restProps = restProps;

いくつかの使用例：

const src = { A: 'a', B: 'b', C: 'c' };
const { rest, props } = Object.rest(src, x => {
    const props = { A, C } = x;
  return { A, C };
});

そして、react拡張機能の使用例：

const { rest, props } = this.restProps(x => {
  const { header, footer } = x;
  return { header, footer };
});

すべての入力は保持する必要があります。 複製が必要なため、私を悩ませているのは小道具の作成者だけです。 私はそれをハックして、破壊されたオブジェクトが_aにあると仮定できると思いますが、それは_危険な_...のようです。
_注_： _aは、 xと同等であるため、実行可能なハッキングではありません。

これがいじくり回すフィドルです。

必要に応じて出力の名前を変更できるため、配列を返す方が理にかなっていると思います。

それをスクラッチすると、小道具の適切な入力ができなくなります。

ここのほとんどの人はこれをreactで使用したいので、ステージ3に到達するまで* .tsxファイルに対してのみこれを実装してみませんか？

Reduxレデューサーは* .tsxファイルとしても書き込むことができます。obj タイプキャスティングインスタンスは、Typeとしてobjに変換する必要があります

これは、reactだけでなく、たとえばreduxレデューサーでも非常に役立ちます。

これに関するタグと欠落しているマイルストーンは少し古くなっていると思います。 これは、TypeScript 2.1でコミットされ、作業中（＃10727）であるためです。 したがって、その価値についてもう議論する必要はありません。

ping @mhegazy

タグを更新しました。 これがまだ実装されていない理由は、その価値ではなく、型システムの実装の複雑さであるということを明確にする必要があります。 それ自体の変換はかなり些細なことです。つまり、 {...x}からObject.assign({}, x)への変換です。 問題は、これらのタイプがどのように事前テストされ、どのように動作するかです。 たとえば、ジェネリック型パラメーターの場合、 Tは{...T}割り当て可能なT 、 {x: number, ...T}についてはどうでしょうか、 Tにメソッドがある場合はどうでしょうか。など。https：//github.com/Microsoft/TypeScript/issues/10727は、必要な型システムの変更のより詳細な説明を提供します。

この機能の理想的な処理に必要な型システムの拡張は簡単ではなく、熱心に取り組んでいるのを見るのは素晴らしいことです。 繰り返しになりますが、

プロパティスプレッドの構文サポートとObject.assignの単純な入力を導入することは、「正しい」実装を待つ間、非常に役立つ一時的なギャップになります。 完璧を善の敵にしないでください。

提案はステージ3に到達したようです： https ：

@ddaghantsxを使用した例は機能しません

この機能の時間枠はありますか？

@ SpyMaster356私はしばらくこれを潜んでいて、それは近いように見えます。 @sandersnは、（少なくとも）過去数週間、これについてお尻を蹴っています。 🙌

こちら（https://github.com/Microsoft/TypeScript/pull/12028）およびこちら（https://github.com/Microsoft/TypeScript/pull/11150）をフォローできます。

誰かがロードマップを更新する必要があります

この機能を使用すると、未知の小道具を割り当てることができるようです。

interface State {
  a: string;
  b: number;
}

let state: State = { a: "a", b: 0 };

state = {...state, x: "x"}; // No error

xがState既知のプロパティではないというエラーを予期していました。 これは機能がどのように機能するかではありませんか？

たとえば、このPRの前の私の現在の回避策は次のとおりです。

state = update(state, { x: "x" }); // Error: Property 'x' is missing in type 'State'.

function update<S extends C, C>(state: S, changes: C): S {
  return Object.assign({}, state, changes);
}

オブジェクトスプレッド/レストでこれを達成することは可能ですか？

ESの提案に従って、オブジェクトのレストとスプレッドはObject.assignと同様に動作します。 プロパティの最後の言及は「勝ちます」。 エラーは報告されません。 例では、 {...state, x:"X"}のタイプは{ a: string, b:number, x:string }です。 このタイプはState割り当てることができるため、割り当ては機能します。 これは、 let state: State = { a: "a", b:0, x: "X" };も許可されると言っているのと同じです。

しかし、それは私が混乱していることです： let state: State = { a: "a", b:0, x: "X" }は私が欲しいものであるエラーObject literal may only specify known properties, and 'x' does not exist in type 'State'を与えます...なぜそれはスプレッドを含むオブジェクトリテラルから出てくるときに有効な割り当てですか？

申し訳ありませんが、オブジェクトリテラルは特殊なケースです。 私の例は間違っていました。 これがより良い例です：

let obj = { a: "a", b:0, x: "X" };
let state: State = obj; // OK

ここでの問題は、かなり主観的なものであるかどうかです。 コンパイラがlet state:State = { a: "a", b:0, x: "X" }場合、 xはタイプミス、リファクタリング後に取り残された古いプロパティ、またはオプションのプロパティのタイプのいずれかである可能性があります。そのため、次のように報告されます。エラー。

あなたがオブジェクトを広げる場合は、のは言わせlet myConfig : State= { a: 1, ...myOtherBigConfigBag}場合、 myOtherBigConfigBag 、あなたが気にしないことをいくつかのプロパティを持って、あなただけの必要aとb 、ここでエラーが発生すると、これら2つのインターフェイスの同期を維持するか、キャストしてこれらのエラーを解消する必要があります。

そうは言った。 この決定を再考する必要があります。 それを追跡するためにhttps://github.com/Microsoft/TypeScript/issues/12717を提出しました。

そうですか。 私は＃12717のあなたのアイデアが大好きです、それはまさに私が考えていたものです。 スプレッドプロップでも実際にそのような動作をしたいのですが、それは非常に主観的であり、いくつかの一般的なJSのユースケースでは煩わしいかもしれないというあなたの指摘を見ることができます。

@aaronbeall同意します。一般的なJSのユースケースでは煩わしいでしょう...ほとんどの場合、オブジェクトが指定されたインターフェイスの形状を持っていることを確認し、スプレッドオブジェクトを直接検査しないようにします。現在の実装は問題ありません。IMO

こんにちはみんな、素晴らしいリリースおめでとうございます！ 今は当然の休息の時間です...私は休息オペレーターに問題があります:)

Reactを使用すると、通常、次のようなコンポーネントが作成されます。

export interface MyLinkProps extends React.HTMLAttributes {
    myUrl: string
}

class MyLink{

    render(){
      const {myUrl, ...attrs } = this.props;
     return <a href={calculate(myUrl)} ...attrs>Click here</a>;
   }
}

問題は、マウスをattrsに合わせると、React.HtmlAttributesではなくすべてのプロパティ（数百）のリストが表示されることです。

typescriptが構造的に型付けされていることは知っていますが、残りの変数に明示的な型を割り当てることは可能でしょうか？

いくつかの選択肢：

    const {myUrl, ...attrs as React.HtmlAttributes } = this.props; //Is not really a casting

    const {myUrl, ...attrs : React.HtmlAttributes } = this.props; //conflicts with ES6?

    const attrs : React.HTMLAttributes; 
    const { myUrl, ...attrs } = this.props;  //re-declare the variable

@bondzええと、私のプロジェクトでの使用の100％ではそうではありません。 :)しかし、別のプロジェクトでは、それは非常に迷惑かもしれません。 私の場合、ReduxとReactを使用しており、不変の状態を多用しています。つまり、状態オブジェクトを更新または作成するには、すべての小道具を新しいオブジェクトリテラルにコピーする必要があります...すべての場合で、100％の型安全性が必要です。正しいデータをターゲット状態インターフェースにコピーしようとしています。 現在、私はこの安全性を確保するために関数を使用していますが、よりクリーンな（読みやすく、表現力豊かで、標準的な構文）ため、オブジェクトスプレッドを使用したいと思います。構造なので、それが非常に主観的であることがわかります。 ＃12717の提案は、良い中間点だと思います（そして、既存のオブジェクトリテラル型の安全性とより一貫性があります）。

https://github.com/Microsoft/TypeScript/issues/2103#issuecomment -145688774
これに対処する前に、提案がステージ3に到達するのを待ちたいと思います。

すでに状態3のようですが、これをサポートする計画はありますか？

ところで、VSCodeは主にES開発に使用しますが、TSはまだ使用していません:)

@evisongこの機能は出荷されており、vsCodeの最新バージョンですでに利用可能です。 vsCodeをバージョン1.8に更新します