JavaScript で MVP - Passive View パターンの実装を考えています。ほとんどの場合、ビューは、プレゼンターがイベント リスナーをアタッチする単純な dom 要素になります。しかし、JavaScript ベースの擬似選択ボックス、自動提案、aria 機能などのウィジェットに関しては、これを JavaScript ビュー クラスの一部にする必要がありますか?それとも、ビューを変更するロジックをプレゼンターの一部にする必要がありますか? 私はjavascriptMVCs ビューを見てきましたが、それらはロジックなしで生成されたテンプレートのみのようです。しかし、私にとっては、html 選択ボックスをリッスンしているプレゼンターと、実際の選択ボックスを模倣する JavaScript ロジックを備えた擬似選択ボックスをリッスンしているプレゼンターとの間に違いはないようです。どちらも、ボックスが内部でどのように機能しているかを気にする必要はありません。変更イベントをリッスンするだけです。
それで、あなたはどう思いますか。ビュークラスの仕事は何ですか。
View オブジェクトは、描画自体を担当する必要があります。パッシブ ビューは、何をすべきかではなく、どのようにすべきかを知っています。独自のイベントを発生させる責任を負う必要があります。カスタム セレクト ボックス ウィジェットだからといって、通常のセレクト ボックスと何ら変わりはありません。
プレゼンターがすべてのビューの責任を引き継いだ場合、ビューはまったく必要ありません。発表者だけでも構いません。
ビューの仕事は、ビュー テクノロジーへのアダプターです。この場合、ビュー テクノロジは、JavaScript を介した HTML 上の jQuery である可能性があります。ビューは、次の 3 つのことを行うように設計する必要があります。
パッシブ ビュー パターンのビューはステートフルではありません。繰り返しますが、ビューは状態を表していません。これが意味することは、すべての状態と状態遷移の知識がプレゼンターによって表されるということです。ビューは、プレゼンターと実際のビュー テクノロジーとの間の間接性を提供する単なる接着剤です。 上記の 3 つの箇条書きを超えて、そこに含まれる情報をどうするかについての知識を要約するものではありません。ビューが一貫した状態にあることを期待してはならないため、これは重要です。ビューの状態を管理する責任を常にプレゼンターに持たせる必要があります。
上記のスタックは、モデル、ビュー、およびプレゼンターの相互作用と、ビュー テクノロジおよびコントローラーとの関係をどのように予測するかを示しています。
JavaScriptMVC のビューはダミーのクライアント側テンプレートです。そのノード コントローラーは、より伝統的なビューの役割を担う傾向があります。