backbone.jsビューに適した粒度は何ですか？

Question

私はバックボーンを採用しています。 既存の大規模なWebアプリ. 。これがうまくいけば、Backbone.jsがアプリ全体を包含するように成長し、有機的に成長したアプリケーションに必要な構造を貸し出すことができます。それが序文です。今問題のために：

ユーザーが読書計画を選択できるようにする選択ボックスがあります。選択が変更されると、ビューはいくつかの記述テキスト、カレンダーインターフェイス、および今日の測定値を完全にマークするための小さなウィジェットを更新します。ウィジェットには、今日のエントリで読み取りごとにチェックボックス（1つ以上）があり、翌日の読書まで続けるためのボタンがあります。 （このインターフェイスの現在の非帯域骨バージョン（完了スキームを差し引いて）の右側に表示できます。 既存のアプリ.

各ビューに適した粒度は何ですか？次の「気分が悪い」と特定しました。

• 含まれるすべてのコントロールを含むタブ自体。
• 選択ボックス
• 選択ボックスに応答する記述テキスト
• 選択ボックスに応答するカレンダー
• 選択ボックスに応答し、以下が含まれる読み取りウィジェットは次のとおりです。
  • オプションで、現在の計画をアクティブにする「開始」ボタン。
  • アクティブ化されると、今日のエントリ内の個々の読み取りに対応する1つ以上のチェックボックスがあります。
  • アクティブ化されると、今日のエントリが完了し、次のエントリが表示される「次の」ボタンがあります。

これらの箇条書きのそれぞれは、独自のビューを取得する必要がありますか？ただの主要なピース（タブ、選択ボックス、ウィジェットを選択）？ 1つ目は、かなりの数のビューをもたらします。 1つ目は、ビューの実装が複雑になる可能性があるようです。何が最高ですか？

ノート： これは非常に主観的な質問として解釈される可能性があることを理解していますが、私はまだBackbone.jsとJavaScript/Dom MVCパターンに頭を包み込みます。 「より経験豊富なバックボーンからの実践者から。ありがとう！

Answer 1

あなたの質問に対する決定的な答えはありません。例示のためのSproutcoreの粒度を見ることができます。

あなたも見ることができます http://vimeo.com/17186379 Yehuda Katzがページのさまざまな部分を更新することの難しさを示しています。

それを見る1つの方法は、どの部分を異なるモデルの変更/イベントで更新する必要があるかを確認し、再レンダリングを最小限に抑えることです。

ごめんなさい、あなたが指摘したように良い答えはありません;）

Answer 2

一般に、あなたの見解の粒度は、特定のUIの複雑さのバランスを見つけることと、ビューの過剰なフラグメント化の間のバランスを見つけることに依存します。私はおそらく、ボタンほど小さなもののビューを使用することはありません（CSSクラスはあなたが本当に必要なのはそれだけです）。

あなたの特定のケースでは、おそらくカレンダーウィジェットのビューがあるので、アプリ内の他の場所で簡単に再利用できます。残りはイベントバインディングを通じて行うことができます。

モデルの更新と再レンダリングに関して、バックボーンを使用したアイデア全体は、その懸念を見解から分離することです。モデルは、属性が変更されたときにイベントを「変更」し、その時点でページに表示され、特定のモデルのデータを表示している場合は、変更が通知され、自分自身を更新できます。