Clever Geek Handbook

Marionette.Regionを使用して起動可能なビューを作成する

クライアントアプリケーションでは、サーバーからデータをダウンロードするプロセスを何らかの形で視覚化する必要がある場合が非常に多くあります。 この記事では、MarionetteJSの再利用可能なMarionette.Regionエリアを介してこの動作を実現する方法について説明します。



私のアプローチは、主にwww.backbonerails.comのスクリーンキャストの作者のアプローチに基づいているとすぐに言わなければなりません 。 これは非常に優れた有用な一連のスクリーンキャストであり、ここで説明されていることだけでなく、MarionetteJSの研究全体としても（それほどではありません）。



目的



したがって、私たちの目標は、ロードプロセスを視覚化するMarionetteJSの再利用可能なコンポーネントを開発することです。 後で示すように、Backbone / Marionetteの場合、ロードの開始および終了のイベントは、モデルの状態の変化の特殊なケースと見なすことができるため、このコンポーネントの目的は、モデルの状態の変化の視覚化としてより抽象的に定式化できます。



BackboneJSを使い始める



誰もが知っているように、MarionetteJSはBackboneJSのアドオンです。 そして、このタスクでBackboneがどのように役立つかから始めたいと思います。 モデル（またはコレクション）とそれを表示するビューがあるとします。 BackboneJSレベルでは、次のようにして問題を解決できました。









図1-データをロードするときのモデルイベント



つまり、ビューはモデルを監視し、Backbone.Modelによって生成された要求および同期イベントを使用して「ブート」状態（たとえば、ある種の読み込みアニメーションを描画）または「同期」状態（読み込みアニメーションを削除）に切り替えるという単純なアイデアです。 ） 簡潔にするために、要求、同期、エラーなどのモデル状態の変更に応答する機能を参照します。 応答性 。 状態の変化とは、モデルデータの変化に関連しないイベントを意味します。



一般に、Backboneを使用すると、Backbone.Model（またはBackbone.Collection）によって生成されたイベントにより目的の動作を簡単に実現できますが、モデルイベントをサブスクライブして処理する必要があるコードの再利用には問題があります。 実際には、応答性を実装する方法の問題には問題はありません。主な問題は、この実装の使用が最も控えめで便利になるように、 どこでこれを行うことができるかです。 どのような場合でもMarionetteJSに基づくよりもうまく機能しないため、Backboneに基づいてコンポーネントを実装する方法の詳細については説明しません。



MarionetteJSビューの使用



ダウンロードを視覚化するタスクに最初に出会ったとき、この問題に関する既製のソリューションがこれほど少ないとは思いませんでした。 グーグルは、Marionette.CollectionView.emptyViewと同様に、Marionette.View.loadingView属性の実装に関する議論を見つけました。 後に、ある種の既製のソリューションが登場しました 。 しかし、正直なところ、モデルを直接表示するビューのレベルでモデルの読み込みを視覚化することは、良いアイデアではないと思います。 一般的なケースでは、ダウンロードを視覚化する方法は、モデルの表示ではなく、誰が表示するかに依存します。 つまり ドキュメントの同じ場所に異なるモデルを表示する場合、読み込みの視覚化はすべてのモデルで均一に見えるはずです。 要するに、このオプションは私たちには適していません。



コントローラーMarionetteJSを使用します



今、私の考えが生まれた根拠に基づいてアプローチについて話す時間です。 彼は、すでに言及した一連のスクリーンキャストのこの号で説明されています。 一言で言えば、このアプローチはモデルをイベントのソースとして使用し、ビューの表示方法を決定する基本的な抽象コントローラーを使用します。 このアプローチの一般的な概要は次のとおりです。

  1. 応答性は、LoadingControler + LoadingViewのペアによって直接実装されます。
  2. LoadingViewを操作するには、ベースコントローラークラスメソッドshow（view、region、options）が使用されます。 派生コントローラーは、このメソッドを使用してビューを表示する必要があります。 このメソッドは、LoadingControllerのインスタンスを作成し、元のビューと表示する領域を提供します。 次に、LoadingControllerは、コンストラクターで（要求イベントではなく）すぐにLoadingViewを指定された領域に置き換えます。
  3. LoadingControllerはモデルを見渡します。 さらに、便利なことに、モデルは明示的に省略できます。デフォルトでは、RealView.collectionとRealView.modelが表示されます。 より具体的には、LoadingControllerはモデルを表示しませんが、そのモデルのデータ要求に関連付けられたxhrオブジェクトを表示します。 これらの要求が完了すると、LoadViewではなく、RealViewが同じ領域に挿入されます。








図2-LoadingView + LoadingControllerを使用する場合のシーケンス図



備考
LoadingControllerは、LoadingViewおよびRealViewではなくMarionette.Regionを介して直接動作しますが、これは作業の一般的な理解にとって重要ではありません。



この相互作用に関係するクラスの図は次のとおりです。









図3-LoadingView + LoadingControllerを使用する場合のクラス図



これは、すでに述べたものの最初の価値あるアプローチです。 しかし、アプリケーションの一般的なアーキテクチャにいくつかの要件を課しているという理由で、私には向いていませんでした。

  1. すべてのコントローラーは、1つの基本クラスから継承し、そのメソッドのみを使用して表現を表示する必要があります。
  2. ブートビューを表示するには、モデルの読み込みを開始し、新しいビューを作成して表示するというシーケンスに従う必要があります。


同時に、私が借りた非常に成功したソリューションがあります：

  1. 明示的に指定せずに調査するモデルを決定する機能。
  2. 荷重の視覚化に対する責任は、モデルの範囲を超えています。




Marionette.Regionを使用します



Marionette.Regionは、ビューが配置されている画面の特定の領域を表し、ビューの有効期間を制御したり、画面に表示される方法でプレゼンテーションから分離したりできます。 エリアにビューを表示したい場合、そのエリアにすでに配置されているビューに何が起こるかを考える必要はありません。ビューは自動的に削除されます。 ビューが画面に表示される方法を変更する必要がある場合、Marionette.Regionを継承してロジックを実装できます。 たとえば、アニメーションを追加して表示方法を変更したり、ビューをドキュメントに挿入して独自の要素でラップしたりする方法を変更できます。 たとえば、 このリリースでは、ダイアログボックス内の任意のビューをラップする独自の領域の実装について説明しています。



私の実装では、主な作業は、Marionette.Regionの継承者である抽象クラスResponsiveRegionで行われます。 モデルイベントに応じて領域の外観を変更し、場合によってはイベント自体をリストするハンドラーを定義するのは、具体的なクラスのみです。 たとえば、透明度、領域の要素の可視性を変更したり、アニメーション付きのオーバーレイを挿入したりできます。一般的には、何でもできます。 設計部分にはあまり注意を払いませんが、抽象クラスに焦点を当てます。 ResponsiveRegionでエリアレベルの応答性を実装した方法は次のとおりです。



  1. ResponsiveRegionの初期化は、Marionette.Regionと同じです。 エリアを定義するレイアウトビュー（LayoutViewから派生）が、標準のMarionette.Regionではなく、ResponsiveRegionエリアの実装を使用することを（宣言的に）示すと仮定します。 



    List.Layout = Marionette.LayoutView.extend({ ... regions : { someRegion : { selector : '#region', regionClass : Marionette.ResponsiveVisiblityRegion } } ... });


  2. この領域にビューを表示するには、region.show（view）（通常のMarionette.Regionと同様）を使用し、デフォルトのパラメーターを使用するか、region.show（view、options）を使用して高度な応答設定を指定できます。
  3. この領域は、送信されたビューをドキュメントに配置します。 彼女はこれを直接ではなく、ラッパーを介して行うことができます。

    例 
      <div class=”js-model-state-sync”>     </div> <div class=”js-model-state-request”>     </div> <div class=”js-model-state-error”>      </div>




  4. エリアは、その中のビューのモデルを表示します（モデルは、region.show（view、options）で明示的に指定されるか、RealView.collectionとRealView.modelが暗黙的に使用されます）。 要求/同期/エラーイベントに応じて、スコープはそのコンテンツの外観を変更します。 たとえば、ラッパー要素の可視性を切り替えます。


シーケンス図は次のようになります。









図4-ResponsiveRegionを使用する場合のシーケンス図



そして、このようなクラス：









図5-ResponsiveRegionを使用する場合のクラス図



備考
実際、まだResponsiveRegionにはレイアウトとコントローラーの依存関係があります。 最初のリンクは、レイアウトビューが実際にResponsiveRegionに依存しているという事実にもかかわらず、通常のMarionette.Regionと同様に実際に動作するため、省略されています。 レイアウト宣言で領域タイプを宣言する方が便利です。 2番目のリンクはオプションであり、コントローラーが応答性オプションを指定する必要がある場合にのみ発生するため、省略されています。



このアプローチを適用することで何を達成できましたか？

  1. 単一の新しいエンティティを作成することなく、Marionette.Regionのみを拡張して、MarionetteJSオブジェクトの構造に完全に適合します。 ほとんどの場合、ResponsiveRegionはその祖先としても使用され、使用されるコンポーネントに関する追加の仮定を行いません。 以前の抽象コントローラーアプローチと比較すると、アプリケーションの構成方法とは関係ありません。Marionetteを使用する場合、ResponsiveRegionを使用できます。
  2. プレゼンテーションがResponsiveRegionで行われている間、常にモデルをレビューします。 ResponsiveRegionは、Marionette.Regionの相続人として、提出の終了を自然に認識しています。これにより、適切なタイミングでモデルイベントの登録を解除し、ゴミを残しません。
  3. モデルのロードの開始および終了のイベントは、その状態の変化の特殊なケースと見なされます。これは、モデルの存続中に任意の回数発生する可能性があります。 これにより、読み込みエラーやモデルデータの検証など、他のモデルイベントに自由に対応できます。




おわりに



上記のアプローチはすべて、状況に応じて正常に適用できます。 しかし、一般的にモデルの状態の変化を視覚化し、特にそのデータをロードするには、Marionette.Regionオプションが最適です。 まず、これは、Marionetteが画面にビューを表示する役割を担っているコンポーネントです。 次に、必要なロジックは1つのコンポーネント内に実装できるほど単純です。 それだけです ここで言及されたもののソースコードと小さな例がここにあります 。



参照資料



  1. backbonerails.com-MarionetteJS Screencastシリーズ
  2. MarionetteJSドキュメント
  3. BackboneJSイベントリスト


More articles:


All Articles