내 모든 녹아웃 사용자 지정 바인딩 처리기에서 항상 업데이트 콜백을 생략했습니다. 내 추론은 내가 init 콜백 내부에서해야 할 일을 모두 할 수 있다는 것이다. 거기에서 계산 된 것을 생성하고, applyBindingsToNode (필요한 경우)를 호출하거나, 구독에 대한 수동 구독을 설정하고 그 구독 내에서 DOM 조작을 수행 할 수 있습니다.바인딩 처리기를 잘못 작성하고 있습니까?
내 관심사는 knockout의 기본 바인딩이 업데이트 콜백 만 사용하여 작성된다는 것입니다.
(업데이트 : 더 이상 값과 다른 바인딩은 init 만 사용합니다.) init 콜백 내부에서 모든 작업을 수행하는 데 단점이 있습니까? 제가 빠진 것이 있습니까? 감사!
init 함수의 계산 및 구독 만들기는 버전 3.0 이후 Knockout에서 완전히 지원됩니다. update을 사용하는 것보다 고급 기술입니다. 이는 모든 종속성을 캡처하고 응답하고 적절한 시간에 구독을 처분 할 수 있도록하기 위해 더 많은주의를 기울여야하기 때문입니다.
var handlerUpdateFn = handler.update;
if (typeof handlerUpdateFn == "function") {
ko.computed(
function() {
handlerUpdateFn(node, getValueAccessor(bindingKey), allBindings,
bindingContext.$data, bindingContext);
},
null,
{ disposeWhenNodeIsRemoved: node }
);
}
환상적! 따라서 업데이트 콜백을 제공하지 않으면 knockout은 계산 된 값을 생성하지 않습니다. –
예, 맞습니다. –
멋진, 나는 정말로 그것이 사실이었다라고 생각하고 있었다, 당신은 나에게 작은 파기를 구했다 :) 고마워! 사랑하는 3.2 btw –
바인딩 처리기의 업데이트 메커니즘을 computed 및 subscriptions으로 바꿀 수 있습니다. 그렇다면이 기능은 사용자 지정 바인딩 처리기를 만들 때 분명히 권장되지 않습니다. 그렇지 않으면 업데이트 기능이 없습니다.
모범 사례를 위반하는 것 외에 추가 구독 및 필요없는 계산을 추가로 사용하면됩니다. 바인딩 처리기 흐름이 실행됩니다. Knockout은 이미 바인딩 핸들러로 전송 된 표현식을 평가하고 업데이트 기능을 실행합니다. 따라서 예상치 못한 동작을 일으킬 수있는 계산 및 구독을 추가하는 것 이외에 추가 작업이 필요합니다. 어느 정도는 필요할 수 있지만 내장 된 업데이트 메커니즘을 사용하지 않으면 문제와 혼란 만 일으킬 수 있습니다.
그렇게하는 것이 문제가되지 않습니다, 그리고 내장 된 바인딩 후 3.0의 일부 지금 : 참고로
자체가 녹아웃에 아주 간단하게 처리됩니다
update기능 (약간 명확성을 위해 수정) 그 구조 (3.1에서는'with','if','ifnot', 3.2에서는'value')를 사용하십시오. 그냥 청소하는 것을 잊지 마세요 : http://www.knockmeout.net/2014/10/knockout-cleaning-up.html –감사합니다. Ryan, 고맙습니다. 나는 KO가 업데이트 콜백을 호출하기로 결심 한 방법을 결정하기 위해 코드를 살펴볼 의향이있었습니다. 나는 그것이 init 콜백 내에서 관찰되는 것을 보았을 것이라고 생각한다. 필자는 업데이트를 호출 할 때 매우 세밀하게 제어하는 것을 선호합니다. 또한, 대부분의 시간 내 맞춤 바인딩 handelrs 바인딩에 내장 된 대량 청소입니다. 이 경우 어쨌든 applyBindingsToNode를 사용하기 만합니다.이 작업은 init에서만 수행해야합니다. –
yes-'update'는 계산에 랩핑되어 실행되는 동안 액세스 된 의존성을 추적합니다. 그래서, 더 큰 통제력을 가지기 위해 자신의 계산을 만드는 것이 좋다면. 'disposeWhenNodeIsRemoved : element' 옵션을 넘기거나'ko.utils.domNodeDisposal.addDisposeCallback'을 사용하면됩니다. (적어도 수동 구독을 처분 할 때 필요합니다). –