私は Durandal を初めて使用し、今のところ気に入っていますが、Durandal を使用するアプリ アーキテクチャの問題について疑問に思っています。たとえば、ko: composeウィジェット、子ビュー、ビューを使用するのに適した時期はいつですか?
私の現在の考えは次のとおりです。
ページ全体にビューを使用する
子ビューを使用するかko: compose、子ページに交互に使用する
複数の場所で使用される子ビューにウィジェットを使用する
それは予想されるユースケースと一致しますか? Durandal が高度にカスタマイズ可能であることは承知していますが、スターター キットの構造に基づいており、既定のユーティリティ (knockout.js、jquery、sammy など) を使用している場合、上記の各要素を使用する適切なタイミングはいつですか?
ようこそ、http://durandaljs.com/pages/docs/にあるドキュメントをよく読んでください。概要がよくわかります。
DOM フラグメントの構成を可能にする Durandal 機能を見るとき、私は通常、ビュー モデルがシングルトン (一意であり、1 つしか存在しない) であるか、コンストラクター (1 つまたは複数である可能性があります) であるかを区別します。慣例により、ビュー モデルは同じ名前の *.html ファイルとペアになります。
たとえば、Durandal のサンプル shell.htmlとJumpStarter の shell.html の shell.htmlを見てください。
どちらの例shell.jsでも、シェルは 1 つしかないためシングルトンを返しますが、2 番目の例では、ナビゲーション html を独自の子ビューに抽出します。ご覧のとおり、子ビューには独自の vm がなく、shell.js代わりに親 (ここでは ) にバインドされています。そうすることで、必要に応じて他の場所で再利用できる、より小さく維持しやすいフラグメントを作成できます。
vm のコンストラクター関数を使用する例については、マスター詳細サンプルを確認してください。
ウィジェットは vm/view((controller.js/view.html) の特別な形式であり、それらが実行されているコンテキストに応じて、これらの要素をわずかに異なる構成にする必要がある場合に考慮される可能性があります。1 つの例として、実行中のフォーム要素が考えられます。インラインではなくモーダル フォームの一部として。
Durandal 1.2 では、構成中にウィジェットのみが追加データを受け取ることができますが、これは次の 2.0 で変更されます。