@andrewtimberlake 는 {{#each range key="@index" as |value idx|}} 하여 문제를 해결하는 것 같습니다.

그러나 버그처럼 보이지만 key 는 다른 목적을위한 것입니다. https://www.emberjs.com/api/ember/release/classes/Ember.Templates.helpers/methods/if?anchor= 마다

나는 여기서 무슨 일이 일어나고 있는지 알고 있다고 생각합니다. 엉망이지만 설명하려고 노력할 것입니다. 많은 엣지 케이스 (테두리 라인 사용자 오류)가이 문제에 기여했으며 버그가 무엇인지, 버그가 아닌지, 무엇을 어떻게 수정해야하는지 잘 모르겠습니다.

주요 🔑

먼저 {{#each}} 에서 key 매개 변수가 수행하는 작업을 설명해야합니다. 요약하자면, 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>

하지만 _how_?

{{#each}} 도우미를 구현하는 가장 순진한 방법은 목록의 내용이 변경 될 때마다 목록의 모든 내용을 지우는 것입니다. 이렇게하려면 _ 최소한 _ 23 개의 작업을 수행해야합니다.

• <li> 노드 3 개 제거
• <li> 노드 4 개 삽입
• 12 개의 텍스트 노드를 삽입합니다 (이름에 1 개, 사이 공백에 1 개,성에 1 개, 4 행 곱하기)
• to-upper-case 도우미를 4 번 호출합니다.

이것은 ... 매우 불필요하고 비싸 보입니다. 처음 세 항목은 변경되지 않았으므로 해당 행에 대한 작업을 건너 뛸 수 있으면 좋을 것입니다.

🔑 @index

더 나은 구현은 기존 행을 재사용하고 불필요한 업데이트를 수행하지 않는 것입니다. 한 가지 아이디어는 단순히 행을 템플릿의 위치와 일치시키는 것입니다. 이것은 본질적으로 key="@index" 역할입니다.

1. 첫 번째 개체 { first: "Yehuda", last: "Katz" } 와 첫 번째 행 <li>Yehuda KATZ</li> :
   1.1. "Yehuda"=== "Yehuda", 할 일 없음
   1.2. (공간에 동적 데이터가 포함되어 있지 않으므로 비교가 필요하지 않습니다.)
   1.3. "Katz"=== "Katz", 헬퍼는 "순수"이므로 to-upper-case 헬퍼를 다시 호출 할 필요가 없음을 알고 있으므로 해당 헬퍼의 출력을 알고 있습니다 ( "KATZ" ) _also_ 변경되지 않았으므로 여기서 할 일이 없습니다.
2. 마찬가지로, 행 2와 3에 대해 할 일이 없습니다
3. DOM에는 네 번째 행이 없으므로 새 행을 삽입하십시오.
   3.1. <li> 노드 삽입
   3.2. 텍스트 노드 ( "Andrew") 삽입
   3.3. 텍스트 노드 (공백) 삽입
   3.4. to-upper-case 도우미 호출 ( "Timberlake"-> "TIMBERLAKE")
   3.5. 텍스트 노드 ( "TIMBERLAKE") 삽입

따라서이 구현을 통해 총 작업 수를 23 개에서 5 개로 줄였습니다. 나쁘지 않다.

목록에 항목 추가

하지만 이제 목록에 _appending_ { first: "Andrew", last: "Timberlake" } 대신 _prepended_하면 어떻게 될까요? 템플릿이 다음 DOM을 생성 할 것으로 예상합니다.

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

하지만 _how_?

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. 두 번째 개체 { first: "Yehuda", last: "Katz" } 를 두 번째 행 <li>Tom DALE</li> , 다른 3 개 작업과 비교합니다.
3. 두 번째 개체 { first: "Tom", last: "Dale" } 를 두 번째 행 <li>Godfrey CHAN</li> , 다른 3 개 작업과 비교합니다.
4. DOM에는 네 번째 행이 없으므로 새 행을 삽입하십시오.
   3.1. <li> 노드 삽입
   3.2. 텍스트 노드 ( "Godfrey") 삽입
   3.3. 텍스트 노드 (공백) 삽입
   3.4. to-upper-case 도우미 호출 ( "Chan"-> "CHAN")
   3.5. 텍스트 노드 ( "CHAN") 삽입

그것은 14 개의 작업입니다. 아야!

🔑 @identity

개념적으로 우리가 접 두든 추가하든, 우리는 여전히 배열의 단일 객체 만 변경 (삽입)하고 있기 때문에 불필요 해 보였습니다. 최적으로, 우리는 추가 시나리오에서했던 것처럼이 케이스를 처리 할 수 ​​있어야합니다.

여기서 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. 데이터가 두 번째 개체 { first: "Yehuda", last: "Katz" } 와 일치하는 ( === ) 기존 행을 찾습니다. <li>Yehuda KATZ</li> 발견 :
   2.1. "Yehuda"=== "Yehuda", 할 일 없음
   2.2. (공간에 동적 데이터가 포함되어 있지 않으므로 비교가 필요하지 않습니다.)
   2.3. "Katz"=== "Katz", 헬퍼는 "순수"이므로 to-upper-case 헬퍼를 다시 호출 할 필요가 없음을 알고 있으므로 해당 헬퍼의 출력을 알고 있습니다 ( "KATZ" ) _also_ 변경되지 않았으므로 여기서 할 일이 없습니다.
3. 마찬가지로 Tom과 Godfrey의 행에는 할 일이 없습니다.
4. 일치하지 않는 개체가있는 모든 행을 제거합니다 (없음,이 경우 수행 할 작업 없음).

이를 통해 최적의 5 가지 작업으로 돌아갑니다.

확장

다시 말하지만 이것은 비교와 부기 비용에 손을 흔드는 것입니다. 사실, 그것들도 무료가 아니며,이 아주 간단한 예에서는 그만한 가치가 없을 수도 있습니다. 그러나 목록이 크고 각 행이 복잡한 구성 요소 (많은 도우미, 계산 된 속성, 하위 구성 요소 등)를 호출한다고 상상해보십시오. 예를 들어 LinkedIn 뉴스 피드를 상상해보십시오. 올바른 행을 올바른 데이터와 일치시키지 않으면 구성 요소의 인수가 잠재적으로 많이 변동될 수 있으며 예상보다 훨씬 많은 DOM 업데이트가 발생할 수 있습니다. 잘못된 DOM 요소를 일치시키고 커서 위치 및 텍스트 선택 상태와 같은 DOM 상태를 잃는 문제도 있습니다.

전반적으로 추가 비교 및 ​​부기 비용은 실제 앱에서 대부분의 시간 동안 쉽게 가치가 있습니다. Ember의 기본값은 key="@identity" 이고 거의 모든 경우에 잘 작동하기 때문에 일반적으로 {{#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>

대부분의 경우, 이것은 매우 드물고, 그것이 나오면 대부분의 경우 Good Enough ™에서 작동합니다. 어떤 이유로이 방법이 작동하지 않는 경우 항상 키 경로 (또는 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. 데이터가 두 번째 개체 undefined 와 일치하는 ( === ) 기존 행을 찾습니다. <input ...>0: ... 발견 (이전의 첫 번째 행) :
   2.1. {{idx}} 텍스트 노드를 1
   2.2. 그렇지 않으면, Ember가 말할 수있는 한,이 행에서 다른 것은 아무것도 변경되지 않았으며 다른 할 일도 없습니다.
3. 데이터가 세 번째 개체 undefined 와 일치하는 ( === ) 기존 행을 찾습니다. undefined 두 번째로 보았으므로 내부 키는 undefined-1 이므로 <input ...>1: ... (이전의 SECOND 행)을 찾았습니다.
   3.1. {{idx}} 텍스트 노드를 2
   3.2. 그렇지 않으면, Ember가 말할 수있는 한,이 행에서 다른 것은 아무것도 변경되지 않았으며 다른 할 일도 없습니다.
4. 마찬가지로 undefined-2 및 undefined-3
5. 마지막으로, 일치하지 않는 undefined-4 행을 제거합니다 (업데이트 후 배열에 undefined 가 하나 더 적으므로).

그래서 이것은 우리가 트위들에서 얻은 결과를 어떻게 얻었는지 설명합니다. 기본적으로 모든 DOM 행이 하나씩 아래로 이동하고 새 행이 맨 위에 삽입되고 {{idx}} 가 나머지 행에 대해 업데이트됩니다.

정말 예상치 못한 부분은 2.2입니다. 첫 번째 확인란 (클릭 한 확인란)이 한 행씩 아래로 이동하여 두 번째 위치로 이동했지만, Ember의 checked 속성이 true 변경 될 것으로 예상했을 것입니다. 바운드 값이 정의되지 않았기 때문에 Ember가 다시 false 로 변경하여 체크를 해제 할 것으로 예상 할 수 있습니다.

그러나 이것은 작동 방식이 아닙니다. 처음에 언급했듯이 DOM에 액세스하는 것은 비용이 많이 듭니다. 여기에는 DOM의 _reading_이 포함됩니다. 업데이트 할 때마다 비교를 위해 DOM에서 최신 값을 읽어야한다면 최적화 목적을 거의 무효화 할 것입니다. 따라서이를 방지하기 위해 DOM에 기록한 마지막 값을 기억하고 DOM에서 다시 읽을 필요없이 현재 값을 캐시 된 값과 비교합니다. 차이가있을 때만 DOM에 새 값을 쓰고 다음 번에 캐시합니다. 이것은 우리가 동일한 "가상 DOM"접근 방식을 공유하는 의미이지만 전체 DOM의 "트리 니스"를 가상화하지 않고 리프 노드에서만 수행합니다.

따라서 TL; DR, checked 속성 (또는 텍스트 필드의 value 속성 등)을 "바인딩"하면 예상대로 작동하지 않습니다. <div>{{this.name}}</div> 를 렌더링하고 jQuery 또는 Chrome 검사기를 사용하여 div 요소의 textContent 를 수동으로 업데이트 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 % 확실하지 않다고 말했습니다. 한편으로는 놀랍고 예상치 못한 일이라는 데 동의합니다. 반면에 이러한 종류의 충돌은 실제 앱에서 매우 드물며 "키"인수를 사용자 정의 할 수있는 이유입니다 (기본 "@identity"키가있는 경우) 기능은 Good Enough ™가 아니므로 해당 기능이 존재합니다.)

@chancancode- 이것은 내가 얼마 전에 열었던 또 다른 문제를 상기시킨다. 비슷한 것이 있다고 생각하십니까? 내가받은 대답 (배열 요소를 설정할 때 set 대신 replace 을 (를) 사용할 필요가 있음) 여전히 나에게 이상하게 보입니다.

@ boris-petrov 나는 그것이 관련이 있다고 생각하지 않는다

안녕하세요, 우리는 ember로 드래그 가능한 목록에 sortablejs를 사용합니다. pls는 각 문제를 재현하기 위해이 데모 를 확인합니다.

단계:

• 한 항목을 마지막으로 드래그
• 선택을 'v2'로 전환

드래그 한 항목이 DOM 트리에 남아있는 것을 볼 수 있습니다.

그러나 항목을 다른 위치 (마지막 항목이 아님)로 드래그하면 잘 작동하는 것 같습니다.