@andrewtimberlakeは、 {{#each range key="@index" as |value idx|}}を使用することで問題を回避できるようです。

しかし、バグのように見えます。 keyは別の目的のためのものです、 https：//www.emberjs.com/api/ember/release/classes/Ember.Templates.helpers/methods/if？anchor =各

私はここで何が起こっているのか知っていると思います。 それは混乱の🍝ですが、私はそれを説明しようとします。 多くのエッジケース（境界線のユーザーエラー）がこれに寄与しましたが、バグであるかどうか、これらのいずれかを修正する方法と方法がよくわかりません。

メジャー🔑

まず、 keyパラメーターが{{#each}}何をするかを説明する必要があります。 TL; DR DOMを最初から作成するのではなく、既存のDOMを再利用することがいつ、どのように意味があるかを判断しようとしています。

私たちの目的のために、「DOMへのタッチ」（たとえば、テキストノードのコンテンツ、属性の更新、コンテンツの追加または削除など）はコストがかかり、可能な限り回避する必要があることを前提として受け入れましょう。

かなり単純なテンプレートに焦点を当てましょう。

<ul>
  {{#each this.names as |name|}}
    <li>{{name.first}} {{to-upper-case name.last}}</li>
  {{/each}}
</ul>

this.namesが...

[
  { first: "Yehuda", last: "Katz" },
  { first: "Tom", last: "Dale" },
  { first: "Godfrey", last: "Chan" }
]

その後、あなたは得るでしょう...

<ul>
  <li>Yehuda KATZ</li>
  <li>Tom DALE</li>
  <li>Godfrey CHAN</li>
</ul>

ここまでは順調ですね。

リストにアイテムを追加する

では、リストに{ first: "Andrew", last: "Timberlake" }を追加するとどうなるでしょうか。 テンプレートが次のDOMを生成することを期待します。

<ul>
  <li>Yehuda KATZ</li>
  <li>Tom DALE</li>
  <li>Godfrey CHAN</li>
  <li>Andrew TIMBERLAKE</li>
</ul>

しかし、_どのように_？

{{#each}}ヘルパーを実装する最も単純な方法は、リストのコンテンツが変更されるたびに、リストのすべてのコンテンツをクリアすることです。 これを行うには、少なくとも23回の操作を実行する必要があります。

• 3つの<li>ノードを削除します
• 4つの<li>ノードを挿入します
• 12個のテキストノードを挿入します（1つは名用、1つはその間のスペース用、もう1つは姓用、4行を掛けたもの）
• to-upper-caseヘルパーを4回呼び出す

これは...非常に不必要で高価なようです。 最初の3つの項目は変更されていないことがわかっているので、これらの行の作業をスキップできれば便利です。

🔑@ index

より良い実装は、既存の行を再利用し、不要な更新を行わないことです。 1つのアイデアは、行をテンプレート内の位置と単純に一致させることです。 これは基本的にkey="@index"が行うことです。

1. 最初のオブジェクト{ first: "Yehuda", last: "Katz" }を最初の行<li>Yehuda KATZ</li>比較します。
   1.1。 「イェフダ」===「イェフダ」、何もしません
   1.2。 （スペースには動的データが含まれていないため、比較は必要ありません）
   1.3。 "Katz" === "Katz"、ヘルパーは "純粋"であるため、 to-upper-caseヘルパーを再度呼び出す必要がないことがわかっています。したがって、そのヘルパー（ "KATZ"）の出力がわかります。 ）_also_は変更されなかったので、ここでは何もしません
2. 同様に、行2と3には何の関係もありません
3. DOMには4行目がないため、新しい行を挿入します
   3.1。 <li>ノードを挿入します
   3.2。 テキストノードを挿入します（ "Andrew"）
   3.3。 テキストノード（スペース）を挿入します
   3.4。 to-upper-caseヘルパーを呼び出します（ "Timberlake"-> "TIMBERLAKE"）
   3.5。 テキストノードを挿入します（ "TIMBERLAKE"）

そのため、この実装では、操作の総数を23から5に減らしました（👋比較のコストを手で振っていますが、私たちの目的では、他の操作と比較して比較的安価であると想定しています）。 悪くない。

リストの前にアイテムを追加する

しかし、今、リストに{ first: "Andrew", last: "Timberlake" }を追加する代わりに、代わりに追加する場合はどうなるでしょうか。 テンプレートが次のDOMを生成することを期待します。

<ul>
  <li>Andrew TIMBERLAKE</li>
  <li>Yehuda KATZ</li>
  <li>Tom DALE</li>
  <li>Godfrey CHAN</li>
</ul>

しかし、_どのように_？

1. 最初のオブジェクト{ first: "Andrew", last: "Timberlake" }を最初の行<li>Yehuda KATZ</li>比較します。
   1.1。 "Andrew"！== "Yehuda"、テキストノードを更新
   1.2。 （スペースには動的データが含まれていないため、比較は必要ありません）
   1.3。 "Timberlake"！== "Katz"、 to-upper-caseヘルパーを再度呼び出します
   1.4。 テキストノードを「KATZ」から「TIMBERLAKE」に更新します
2. 2番目のオブジェクト{ first: "Yehuda", last: "Katz" }を2番目の行<li>Tom DALE</li> 、別の3つの操作と比較します
3. 2番目のオブジェクト{ first: "Tom", last: "Dale" }を2番目の行<li>Godfrey CHAN</li> 、別の3つの操作と比較します
4. DOMには4行目がないため、新しい行を挿入します
   3.1。 <li>ノードを挿入します
   3.2。 テキストノードを挿入します（ "Godfrey"）
   3.3。 テキストノード（スペース）を挿入します
   3.4。 to-upper-caseヘルパーを呼び出します（「Chan」->「CHAN」）
   3.5。 テキストノードを挿入します（ "CHAN"）

これは14回の操作です。 痛い！

🔑@ identity

概念的には、追加するか追加するかに関係なく、配列内の1つのオブジェクトのみを変更（挿入）しているため、これは不要に思えました。 最適には、追加シナリオで行ったのと同じように、このケースを処理できるはずです。

ここでkey="@identity"が登場します。配列内の要素の_order_に依存する代わりに、JavaScriptオブジェクトID（ === ）を使用します。

1. データが最初のオブジェクト{ first: "Andrew", last: "Timberlake" }一致する（ === ）既存の行を検索します。 何も見つからなかったので、新しい行を挿入（追加）します。
   1.1。 <li>ノードを挿入します
   1.2。 テキストノードを挿入します（ "Andrew"）
   1.3。 テキストノード（スペース）を挿入します
   1.4。 to-upper-caseヘルパーを呼び出します（ "Timberlake"-> "TIMBERLAKE"）
   1.5。 テキストノードを挿入します（ "TIMBERLAKE"）
2. データが2番目のオブジェクト{ first: "Yehuda", last: "Katz" }一致する（ === ）既存の行を検索します。 <li>Yehuda KATZ</li>見つかりました：
   2.1。 「イェフダ」===「イェフダ」、何もしません
   2.2。 （スペースには動的データが含まれていないため、比較は必要ありません）
   2.3。 "Katz" === "Katz"、ヘルパーは "純粋"であるため、 to-upper-caseヘルパーを再度呼び出す必要がないことがわかっています。したがって、そのヘルパー（ "KATZ"）の出力がわかります。 ）_also_は変更されなかったので、ここでは何もしません
3. 同様に、トムとゴッドフリーの列には何の関係もありません
4. 一致しないオブジェクトを含むすべての行を削除します（なし、この場合は何もしません）

これで、最適な5つの操作に戻ります。

スケールアップする

繰り返しますが、これは👋比較と簿記のコストを手で振っています。 確かに、それらも無料ではなく、この非常に単純な例では、それらは価値がないかもしれません。 しかし、リストが大きく、各行が複雑なコンポーネント（多くのヘルパー、計算されたプロパティ、サブコンポーネントなど）を呼び出すと想像してください。 たとえば、LinkedInのニュースフィードを想像してみてください。 適切な行と適切なデータを一致させないと、コンポーネントの引数が大量にチャーンする可能性があり、予想よりもはるかに多くのDOM更新が発生する可能性があります。 間違ったDOM要素を一致させたり、カーソル位置やテキスト選択状態などのDOM状態を失ったりすることにも問題があります。

全体として、追加の比較と簿記のコストは、実際のアプリではほとんどの場合簡単に価値があります。 key="@identity"はEmberのデフォルトであり、ほとんどすべての場合に適切に機能するため、 {{#each}}を使用する場合、通常はkey引数の設定について心配する必要はありません。

衝突💥

しかし、待ってください、問題があります。 この場合はどうですか？

const YEHUDA = { first: "Yehuda", last: "Katz" };
const TOM = { first: "Tom", last: "Dale" };
const GODFREY = { first: "Godfrey", last: "Chan" };

this.list = [
  YEHUDA,
  TOM,
  GODFREY,
  TOM, // duplicate
  YEHUDA, // duplicate
  YEHUDA, // duplicate
  YEHUDA // duplicate
];

ここでの問題は、同じオブジェクトが同じリストに複数回表示される可能性があることです。 これは、単純な@identityアルゴリズム、特に「データが一致する既存の行を検索する（ === ）...」と言った部分を壊します。これは、データとDOMの関係が1の場合にのみ機能します。 ：1、これはこの場合は当てはまりません。 これは実際にはありそうもないように思われるかもしれませんが、フレームワークとして、私たちはそれを処理する必要があります。

これを回避するために、一種のハイブリッドアプローチを使用してこれらの衝突を処理します。 内部的には、キーからDOMへのマッピングは次のようになります。

"YEHUDA" => <li>Yehuda...</li>
"TOM" => <li>Tom...</li>
"GODFREY" => <li>Godfrey...</li>
"TOM-1" => <li>Tom...</li>
"YEHUDA-1" => <li>Yehuda...</li>
"YEHUDA-2" => <li>Yehuda...</li>
"YEHUDA-3" => <li>Yehuda...</li>

ほとんどの場合、これは非常にまれであり、発生した場合、これはほとんどの場合GoodEnough™で機能します。 何らかの理由でこれが機能しない場合は、いつでもキーパス（またはRFC 321のさらに高度なキーイングメカニズム）を使用できます。

「🐛」に戻る

すべての話が終わったので、Twiddleのシナリオを見る準備ができました。

基本的に、次のリストから始めました： [undefined, undefined, undefined, undefined, undefined] 。

無関係な注意： Array(5)は[undefined, undefined, undefined, undefined, undefined]と同じではありません。 それはあなたが一般的に避けるべきものである「穴あき配列」を生成します。 ただし、「穴」にアクセスすると実際にundefined返されるため、このバグとは関係ありません。 したがって、私たちの_非常に狭い_目的のためだけに、それらは同じです。

キーを指定しなかったため、Emberはデフォルトで@identityを使用します。 さらに、それらは衝突であるため、次のような結果になりました。

"undefined" => <input ...> 0: ...,
"undefined-1" => <input ...> 1: ...,
"undefined-2" => <input ...> 2: ...,
"undefined-3" => <input ...> 3: ...,
"undefined-4" => <input ...> 4: ...

ここで、最初のチェックボックスをクリックするとします。

1. これにより、選択ボックスのデフォルトの動作がトリガーされます。チェックされた状態がtrueに変更されます。
2. クリックイベントがトリガーされ、 {{action}}修飾子によってインターセプトされ、 makeChangeメソッドに再ディスパッチされます。
3. リストを[true, undefined, undefined, undefined, undefined]ます。
4. DOMを更新します。

DOMはどのように更新されますか？

1. データが最初のオブジェクトtrue一致する（ === ）既存の行を検索します。 何も見つからなかったので、新しい行を挿入（追加）します<input checked=true ...>0: true...
2. データが2番目のオブジェクトundefined一致する（ === ）既存の行を検索します。 <input ...>0: ... （以前は最初の行）が見つかりました：
   2.1。 {{idx}}テキストノードを1更新します
   2.2。 それ以外の場合、Emberが知る限り、この行では他に何も変更されておらず、他に何もする必要はありません。
3. データが3番目のオブジェクトundefined一致する（ === ）既存の行を検索します。 undefinedを2回目に見たので、内部キーはundefined-1であるため、 <input ...>1: ... （以前は2番目の行）が見つかりました。
   3.1。 {{idx}}テキストノードを2更新します
   3.2。 それ以外の場合、Emberが知る限り、この行では他に何も変更されておらず、他に何もする必要はありません。
4. 同様に、 undefined-2とundefined-3更新します
5. 最後に、一致しないundefined-4行を削除します（更新後に配列内のundefinedが1つ少なくなるため）

だから、これはあなたがいじくり回したときにどのように出力を得たかを説明しています。 基本的に、すべてのDOM行が1つ下にシフトし、新しい行が一番上に挿入され、残りは{{idx}}が更新されます。

本当に予想外の部分は2.2です。 最初のチェックボックス（クリックされたチェックボックス）が1行下がって2番目の位置に移動したとしても、Emberのcheckedプロパティがtrueに変更されていることを期待していたでしょう。バインドされた値は未定義であるため、Emberがそれをfalseに戻し、チェックを外すことを期待できます。

しかし、これはそれがどのように機能するかではありません。 冒頭で述べたように、DOMへのアクセスにはコストがかかります。 これには、DOMからの_読み取り_が含まれます。 更新のたびに、比較のためにDOMから最新の値を読み取らなければならない場合、最適化の目的はほとんど損なわれます。 したがって、それを回避するために、DOMに書き込んだ最後の値を記憶し、DOMから読み戻すことなく、現在の値をキャッシュされた値と比較しました。 違いがある場合にのみ、新しい値をDOMに書き込みます（そして次回のためにキャッシュします）。 これは、同じ「仮想DOM」アプローチを共有するという意味ですが、DOM全体の「ツリー性」を仮想化するのではなく、リーフノードでのみ実行します。

したがって、TL; DR、 checkedプロパティ（またはテキストフィールドのvalueプロパティなど）を「バインド」すると、実際には期待どおりに機能しません。 <div>{{this.name}}</div>をレンダリングし、 jQueryまたはchromeインスペクターを使用してdiv要素のtextContentを手動で更新した場合を想像してみてください。 Emberがそれに気づき、 this.nameを更新するとは思わなかったでしょう。 これは基本的に同じことです。 checkedプロパティの更新はEmberの外部で行われたため（ブラウザのチェックボックスのデフォルトの動作を介して）、Emberはそれを認識しません。

これが{{input}}ヘルパーが存在する理由です。 関連するイベントリスナーを基になるHTML要素に登録し、操作を適切なプロパティの変更に反映して、関係者（レンダリングレイヤーなど）に通知できるようにする必要があります。

それが私たちをどこに残すのかわかりません。 これが驚くべき理由は理解できますが、これは一連の不幸なユーザーエラーであると言いがちです。 おそらく、これらのプロパティを入力要素にバインドすることに対してリントする必要がありますか？

関連コード：

https://github.com/emberjs/ember.js/blob/c24bc23e4139c90c8d8d96c4234d9c0c19e5c594/packages/@ember/ -internals / glimmer / lib / utils / iterable.ts＃L390-L391

https://github.com/emberjs/ember.js/blob/c24bc23e4139c90c8d8d96c4234d9c0c19e5c594/packages/@ember/ -internals / glimmer / lib / utils / iterable.ts＃L436-L445

https://github.com/emberjs/ember.js/blob/c24bc23e4139c90c8d8d96c4234d9c0c19e5c594/packages/@ember/ -internals / glimmer / lib / utils / iterable.ts＃L451-L466

https://github.com/glimmerjs/glimmer-vm/blob/021dba0b8981488ee81c6a4495b95f372ae85743/packages/%40glimmer/runtime/lib/vm/attributes/dynamic.ts#L106 -L112

@ chancancode-すばらしい説明をありがとう。 それは、そのようなすべてのエラーを防ぐために、 <input ... >を使用してはならず、 {{input ...}}のみを使用する必要があることを意味しますか？

@ boris-petrov「このURLをクリップボードにコピーする」ような読み取り専用テキストフィールドのように、受け入れられる場合がいくつかあります。または、入力要素+ {{action}}を使用して傍受することができます。 DOMイベントを実行し、プロパティの更新を手動で反映します（これは、 @identity衝突が発生したことを除いて、twiddleが実行しようとしたことです）が、ある時点で{{input}}再実装しているだけです。すでに処理されているすべてのエッジケースを処理します。 したがって、すべてではないにしても、ほとんどの場合、 {{input}}使用する必要があると言うのは_おそらく_公正だと思います。

ただし、キーとの衝突があるこの場合は、まだ「修正」されていません。 https://ember-twiddle.com/0f2369021128e2ae0c445155df5bb034?openFiles=templates.application.hbs%2Cを参照して

だから私は言った、私はこれについて何をすべきか100％わからない。 意外で予想外のことですが、実際のアプリではこの種の衝突は非常にまれであり、「key」引数をカスタマイズできるのはそのためです（これは、デフォルトの「@identity」キーの場合です）。機能はGoodEnough™ではないため、その機能が存在します）。

@ chancancode-これは、私がしばらく前に開いた別の問題を思い出させます。 そこに似たようなものがあると思いますか？ そこで受け取った答え（配列要素を設定するときにset代わりにreplaceを使用する必要性について）はまだ私には奇妙に思えます。

@ boris-petrov私はそれが関連しているとは思わない

こんにちは、残り火のドラッグ可能なリストにはsortablejsを使用します。 plsは、このデモをチェックして、各問題を再現します。

ステップ：

• 任意の1つのアイテムを最後までドラッグします
• 選択を「v2」に切り替えます

ドラッグされたアイテムがDOMツリーにとどまっていることがわかります。

しかし、アイテムを他の位置（最後のアイテムではない）にドラッグすると、うまくいくようです。