백본 js .listenTo 대 .on

백본 js .listenTo 대 .on

---

다음 두 줄의 코드의 장점과 단점은 무엇입니까? 동일한 작업을 수행하는 데 두 가지 다른 방법이있는 이유를 이해할 수 없습니다.

this.listenTo(app.Todos, 'change:completed', this.filterOne);
app.Todos.on('change:completed', this.filterOne);

또한 .on을 사용할 때 기본 컨텍스트를 어떻게 결정합니까?

---

listenTostopListening뷰가 제거 될 때 호출되는 동안 이러한 리스너가 자동으로 제거되기 때문에 더 새롭고 더 나은 옵션 remove()입니다. listenTo보기 인스턴스 자체가 오래 전에 사라지고 더 이상 DOM에 없어도보기 메서드가 모델의 이벤트 리스너로 참조 되었기 때문에 그 이전에는 팬텀보기가 영원히 계속되는 (메모리 누수 및 오동작 유발) 정말 교활한 문제가있었습니다.

에 대한 백 스토리를 읽으려면 listenTo백본 github 저장소 listenTo에서 더 긴 문제 토론 중 일부를 검색하십시오 .

기본 컨텍스트와 관련하여 몇 가지 사항이 this다음과 같이 바인딩 될 수 있습니다 .

• 를 통해 바인딩을 수행하면 this.listenTo항상 뷰 인스턴스가됩니다 (Wim Leers가 주석에서 지적함).
• 없이는 this.listenTo이야기가 복잡해집니다.
  • 기타 이벤트의 경우 전역 개체가됩니다 (이를 피하는 것이 가장 좋습니다).
  • DOM 이벤트의 경우 일반 DOM 이벤트 바인딩과 마찬가지로 소스 요소가됩니다.
  • 명시 적 컨텍스트 (에 대한 세 번째 인수 foo.on) 를 제공하면 백본이이를 사용하므로 더 강력한 접근 방식입니다.
  • ECMA 표준을 사용하는 경우 function () {//your event handler}.bind(this)컨텍스트를 수동으로 제어 할 수도 있습니다 (권장 됨).
  • @mu가 지적 _.bind했거나 $.proxyECMA에 대한 대안이 있습니다.function.bind
  • 백본 뷰의 경우 뷰 메소드가 이벤트 핸들러로 사용될 때 this.bindAll('onClick', ...)뷰 인스턴스가 this컨텍스트 가되도록합니다.
• 뷰의 표준 events속성 을 사용하여 연결된 모든 이벤트 는 백본에 의해 뷰 인스턴스에 자동으로 바인딩됩니다 (벨트 및 멜빵입니다 bindAll).

따라서 몇 가지 지침으로 요약하면 다음과 같습니다.

• events간결하고 정확하므로 가능한 한 속성을 사용 하십시오.
• this.listenTo모델 및 컬렉션에 대한 모든 바인딩에 사용
• 추가 바인딩은 선호하는 방법을 사용하여 컨텍스트를 안정적으로 바인딩해야합니다. 나는 보통 ECMA를 사용 Function.bind하기 때문에 표준이지만 여기에는 몇 가지 좋은 옵션이 있습니다.

---

를 사용하면 listenTo이벤트를 수신하려는 객체가 첫 번째 인수로 전달됩니다. 의 경우 on실제로는 해당 객체의 메서드입니다.

listenToover 의 장점은 다음 과 on같습니다.

• 리스너는 모든 이벤트 핸들러를 추적하므로 필요할 때 한 번에 모두 제거하기가 더 쉽습니다.

• 콜백의 컨텍스트는 항상 리스너 자체로 설정됩니다.

참고 URL : https://stackoverflow.com/questions/16823746/backbone-js-listento-vs-on