궁금한 점은 현재 'foreach'바인딩이 배열을 반복하는 방식과 같이 링크 된 목록을 반복하는 'foreach'바인딩을 만드는 방법이 궁금합니다.Knockout.js 연결된 목록에 대한 'foreach'바인딩
나는 a jsFiddle for tinkering을 만들었습니다.
링크드리스트는 Knockout.js와 함께 사용하는 유용한 관용구가 될 수 있다고 생각합니다. 특히, DOM이 추가되었거나 제거 될 때 (즉, 요소가 추가/제거 될 때 전체 목록이 업데이트되지 않음) 요소의 업데이트 만 수행되며 목록의 중간에 추가/제거하는 것은 복잡합니다. 배열에 대한 O (1) 대 O (n).
이것은 좋은 생각이지만, 불행히도 나는 그것이 가능하지 않다고 생각합니다.
목록의 머리 부분에 대한 관찰 가능 항목과 모든 요소에 대한 '다음'관찰 가능 부분을 구독해야합니다.
관측 대상 중 어느 것이 변경을 유발했는지 알 수 없으면 아무런 이점이 없다는 것이 문제입니다. 목록의 중간에서 무언가를 편집하면 전체 구조를 반복하지 않고도 foreach 바인딩이 DOM의 해당 부분을 업데이트 할 수 있어야합니다. 바인딩은 현재 이것을 허용하지 않습니다. 바인딩이 여러 관찰 데이터를 구독하는 경우 해당 메서드 중 하나라도 변경되면 변경된 메서드를 모르는 채 update 메서드가 호출됩니다.
또한이 작업이 가능할지라도 추가 ko.observable() 구조 및 구독은 모두 심각한 오버 헤드가됩니다. 단지 다른 배열 요소를 갖는 것 대신에 세 개의 관측 값.
DOM을 불필요하게 변경하지 않으려면 새 구조체를 이전 구조체와 비교하고 관련 변경 사항을 적용 할 수 있지만 어쨌든 배열을 사용할 때는이 작업을 수행 할 수 있습니다 (내장형 foreach 바인딩이 최적화).
배열 기반 foreach는 이미 매우 성능이 뛰어납니다. DOM 요소는 네세 사리 (nessesary)로만 추가/제거됩니다. 물론 전체 배열은 변경 사항을 검사하지만 꽤 빠릅니다 (배열에 대해 거친 변경 신호 만 있습니다). 사용 된 거리 알고리즘 덕분에 무작위 삽입 또는 삭제가 빠릅니다.
게시물 주셔서 감사합니다. 제 3 항의 문제를 이해하지 못합니다 - 제발 좀 더 자세히 설명해 주시겠습니까? 변화를 촉발시킨 관측자가 필요한 이유는 무엇입니까? 이전 요소를 의미합니까? 나는이 구조가 필연적으로 양방향 링크 된 목록 (이 이유 및 다른 이유로)이 될 것이라고 기대하고 있습니다. 문제가 해결 될 수도 있습니다. 걱정되는 부분은 모든 ko.observables의 오버 헤드입니다. 나는 (아마도 실수로) 매우 반복적이라고 생각했습니다. 단,이 반복자가 없어야하는 구독 계층의 맨 아래에있는 경우는 예외입니다. –
대체 접근법은 링크 된 목록을 가로 지르는 '계산 된'관측 가능성을 갖는 것이고, 각 요소를 평면 배열, 정렬 된 배열에 넣는 것, 그러면 그것에 대해 'foreach'할 수 있습니다. 이것이 당신이 원하는 것을 성취 할 수있게 해 줄 것입니까? – WickyNilliams
답변을 업데이트했습니다. 어떻게 계산 된 결과가 도움이되는지 알지 못한다. 단지 값 비싼 배열이된다. 나는 처음부터 배열을 사용하지 않는 이유를 볼 수 없다. 해당 섹션을 처음부터 업데이트하지 않는 새로운 바인딩을위한 공간이 있지만 배열을 계속 사용합니다. – SystemParadox