角度性能 - パイプ対ゲッター

Question

たとえば、私はToDoアイテムで単純な配列を持っています。とを未完了を完了
：

[ 
    { name: 'Item 1', completed: false }, 
    { name: 'Item 2', completed: false } 
    { name: 'Item 3', completed: true } 
    { name: 'Item 4', completed: false } 
] 

この配列は2行で表示されなければなりません。

私には2つの選択肢があります。
1ゲッター。

public get doneItems() { 
    // filter and return only done items. And similar method for not done 
} 

2パイプ。

質問：
あなたはオプションは、より良い性能を持っているいくつかのメトリクスや提案を持っていますか、場合に更新され、アレイ（、更新、追加、削除）、より複雑なアイテムやページ上の100項目まではライブがあるはずです。
ありがとうございます！

Answer 1

@mokがアクセントにしているように、あなたのケースでは全く問題はありませんが、あなたの質問に正確に答えれば...ちょっと推測してみましょう。

ゲッター。変更検出サイクル中に何十億回も呼び出すことができます。その内部にフィルタリングを実装すると、ゲッターが同じオブジェクトを含む新しい配列を返すたびにフィルタリングを実装します。これにより、毎回同じ結果を持つngForディレクティブのdiffの再計算が一定になります。繰り返しますが、100アイテムの間、このオーバーヘッドは全く測定できません（角度のあるチームは本当にすばらしい仕事を最適化しました！）が、まだ不必要な操作の束です。本当に最適なオプションはありません。

パイプ。ここで良い解決策を得るには、2つのことを行う必要があります：a）pureフィルターを実装します。 2）配列が不変であることを確認してください。この配列は更新できません。 - 配列の各操作（追加/削除/移動/項目の変更）はが新しい配列を生成する必要があります。こうすることで、角度を使用することで、ソース配列やフィルタリング値を変更しない限り、変化の検出サイクル中にビューを更新するためのアクションはまったく必要ありません。したがって、ここでは良い解決策があるかもしれませんが、慎重で思慮深いコーディングが少し必要です。

ここでも別のオプションがあります。 DoneArrayとNotDoneArrayの2つの部分配列を作ることができます（ネーミングは愚かですが、もっとうまくいくことができます）。） - メイン配列を変更した瞬間にそれらを埋めます。これを使うと、2つのダムゲッターを作成して、それらの配列を返すだけで、それらのゲッターをテンプレート内で使うことができます。メイン配列が変更されない限り、これらの配列は不変であるため、変更検出で追加のオーバーヘッドが発生しません。この場合、特別なパイプはまったく必要ありません。単純に* ngForと一緒に行ってください。ここの欠点は、データを格納するのに必要なメモリの2倍ですが、やはり100個のアイテムだけです...誰が気にしますか？ :)

PS。非常に重要なことを忘れてしまった - このような方法でパイプを使用することを強く示唆する角度の書類にはsome explanationsもあります。そのことを念頭に置いて、解凍後にソリューションが機能するかどうかを確認する必要があります。