모든 사람들이 여전히 render 메소드를 사용하여 부모 - 자식보기를 구성하고 있습니까?

Question

나는 스스로 백본 해커라고 부른다. 프레임 워크가 할 수있는 일과 그 한계가있는 곳을 안다. 또한 몇 가지 템플릿 프레임 워크에 대한 경험이 있습니다.

사람들은 복잡하고 중첩 된 뷰를 만드는 방법을 설명하는 많은 자습서를 보았으며 대부분이 템플릿을 사용하여 부분적으로 만들었고 부모 뷰의 render 메서드 내에서 템플릿 기반 자식을 결합했습니다. 보기

나를 위해, 이것은 왜 선언적 코드에서 레이아웃 렌더링을 다루어야하는지 이해가 가지 않습니다. Flex에서 왔기 때문에 나는 그렇게하지 않는다는 것을 배웠습니다. 레이아웃 설명과 변수 바인딩을 항상 마크 업에 남긴 다음 이벤트를이 마크 업을 사용하는 선언적 (View 인스턴스) 코드로 처리했습니다.

그러나 테스트 한 템플릿 프레임 워크 중 어느 것도 중첩 된보기가있는 복잡한 마크 업을 만들 수 없습니다. 하나는 템플릿에서 템플릿을 실제로 호출 할 수 없으므로 View 객체를 인스턴스화합니다. 이것은 기술적으로 가능합니다. 특히 데이터 속성을 사용하면 형식 이름을 지정할 수 있습니다.

루트 레벨 View 클래스의 모든 렌더링 메소드는이 템플릿을 HTML 마크 업으로 변환 한 다음 자식 객체의 유형을 알아 내고 그 중 하나에 대한 하위보기 인스턴스를 만들고, 그 자식 객체가 자식 객체 자체를 가져야하는 경우에 대비하여 추가로 보관하십시오. 모든 뷰에는 모델 컨텍스트가 제공됩니다. 기본적으로 모든 보일러 플레이트 단계는 우리가 항상 처리하지만 Backbone.View 수준에서 자동화됩니다.

누구든지 이것에 대해 생각하고 계십니까? 왜 아무도 이것을 사용하지 않는 것입니까?

Answer 1

렌더링을 전혀 사용할 필요가 없으며 주로 코드를 변경 한 후 다시 렌더링하기 위해 예약되어 있습니다. CSS 선택기를 기반으로 뷰를 직접 바인딩 할 수 있습니다 (이에 대한 문서 참조).

또한 데이터 바인딩을 크게 단순화하고 필요한 '수동'인력을 줄여주는 백본 모델 바인딩 확장이 있습니다. 그것을 확인하고 싶을 수도 있습니다.

http://github.com/derickbailey/backbone.modelbinding

마지막으로 나는 부모 - 자식 관계를 렌더링에 대해 이런 말을합니다. Do not call the DOM in a loop. 이것은 매우 비효율적이며 적어도 하나의 이유는 사람들이 부모 렌더링 방법에서만 부모 - 자식 관계를 구축 할 것입니다. jQuery를 사용하여 각각의 자식을 렌더링하면 브라우저에서 많은 작업이 수행됩니다 (현대적인 브라우저에서이를 인식하지 못하면 IE8에서 시도해보십시오).

Answer 2

render 메서드에서 자식 뷰를 인스턴스화하는 것이 의미가 없다는 데 동의합니다. 나는 종종 추가 인수를 전달하기 원하기 때문에, 아이 뷰를 초기화 할 때 나는 완전히 프로세스를 자동화하기 위해 주저 것 있지만 예 :

var childCollection = someLogicToCreateTheChildCollection(); 

new ChildView({ 
    collection : childCollection 
}); 

그래서, 내가 필요한 모든 아이 뷰를 만드는 대신에 일을 끝낼 것 initialize에 입력 한 다음 render에 템플릿을 렌더링하고 DOM의 요소에 자식 뷰를 할당합니다.

내 렌더링 함수가 DOM 순서를 선언하는 함수가 아니기 때문에 (많은 예제가 추가로 표시되는 것처럼) 템플릿에서 DOM 순서와 렌더링 함수를 설정합니다. setElement().render()은 자식 뷰입니다.