なぜ誰もがrenderメソッドを使用して親子ビューを構築していますか？

Question

私は自分自身をバックボーンハッカーと呼んでいます。私はフレームワークが何をすることができるのか、その限界がどこにあるのかを知っています。私はまた、いくつかのテンプレートフレームワークでいくつかの経験を持っています。

多くのチュートリアルでは、複雑なネストされたビューの作成方法を説明していますが、そのほとんどはテンプレートを使用して部分的に作成してから、親ビューのrenderメソッド内でテンプレート化された子を結合します表示

私にとって、これはなぜ宣言的なコードでレイアウトレンダリングに対処すべきか理解できません。フレックスから来て、私はそれを決してしないように教えられました。私はいつも、レイアウト記述と変数バインディングをマークアップに残し、イベント処理はこのマークアップを使用する宣言（Viewインスタンス）コードに任せました。

私がテストしたテンプレートフレームワークはありませんが、ネストされたビューで複雑なマークアップを作成することはできません。テンプレートから実際にテンプレートを呼び出すことはできず、したがってViewオブジェクトをインスタンス化することはできません。これは技術的に可能ですが、特にデータ属性を使用して、型名を指定することができます。

次に、ルートレベルのViewクラスのすべてのレンダリングメソッドは、このテンプレートをHTMLマークアップに変換し、子オブジェクトのタイプを調べ、そのいずれかの子ビューインスタンスを作成し、それらの子オブジェクトが子オブジェクトを持つべきである場合には、さらにそれを保つ。すべてのビューにモデルコンテキストが与えられます。基本的には、私たちが常に処理する標準的な手順ですが、Backbone.Viewレベルで自動化されています。

誰もがこれについて考えていますか？なぜ誰もこれを使用していないようですか？

Answer 1

レンダリングはまったく使用する必要はなく、主にコードの変更後にレンダリングするために予約されています。 CSSセレクタに基づいてビューを直接バインドすることができます（これについては、ドキュメントを参照してください）。

さらに、データバインディングを大幅に簡素化し、必要とされる「手作業」労力を軽減するモデル結合拡張があります。あなたはそれをチェックしたいかもしれません。

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

最後に、私は、親子関係のレンダリングについては、これを言うだろう。 Do not call the DOM in a loop。これは信じられないほど非効率的であり、少なくとも1つの理由で人々は親のレンダリング方法でのみ親子関係を構築するでしょう。それぞれの子供がjQueryを使って自分自身をレンダリングすると、ブラウザーで多くの作業が行われます（現代のブラウザーでこれを気付かない場合は、IE8で試してみてください）。

Answer 2

renderメソッドで子ビューをインスタンス化することは意味をなさないことに同意します。私は、多くの場合、追加の引数に渡したいので、子ビューを初期化するとき、私は完全にプロセスを自動化するために躊躇するだろうが、例えば：

var childCollection = someLogicToCreateTheChildCollection(); 

new ChildView({ 
    collection : childCollection 
}); 

だから、私は私が必要とするすべての子ビューを作成している代わりにやって終わるものをinitializeで、次にrenderでテンプレートをレンダリングし、子ビューをDOMの要素に割り当てます。

この方法では、私のレンダー機能はDOMオーダーを宣言するものではありません（多くの例が追加によって表示されます）。テンプレートはDOMオーダーとレンダー機能を設定します。setElement().render()は子ビューです。