ホームページ > 記事 > ウェブフロントエンド > Ember-Data の機能を深く理解する (パート 2)_html/css_WEB-ITnose
前に書きました
最近、新しい仕事に変わり、たくさんの新しい技術を学ばなければならず、ブログを続けない言い訳もたくさん見つけました。残りの時間の多くが使われずに無駄になることはよくありますが、これは私が望んでいることではありません、ブログを書き続けて、その中に入るように努めます。トップ100ブログのことを念頭に置いてください。
深夜、コンピューターの隣。
記事インデックスJS フロントエンド フレームワーク Ember.js シリーズ
2. Ember-Data を使用する
Ember-Data をより効果的に使用するには、Store をメモリ キャッシュとして考える必要があります。データモデルを復元および保存します。実際、ストアは、バインドされたアダプターを通じてサーバーからデータを取得する役割も担っています。
アダプターをカスタマイズすることもできます:
またはシリアライザーをカスタマイズします:
これはカスタム シナリオを指摘するためのものであり、次に詳しく分析します。
データを取得する簡単な方法は次の 2 つです:
その他の例については、以下を参照してください: http://emberjs.com/api/data/classes/DS.Store.html
上記のモデルの mainMenu タイプと Children タイプは両方ともmainMenu、「無限」ツリーの概念を形成し、ネストされたノード オブジェクトをループします。次の図は、モデル内の mainMenu と Chart の間の関係図を示しています。
注: 上の図の OneToOne、OneToMany などは曖昧です。 、著者の写真 グラフを OneToNone、ManyToNone に変更する必要があります。
ここで、mainMenu には、上位レベルの参照関係を識別する親ノード、子ノードのコレクションを表す子ノード、そして最後にチャート データを表す 1 対 1 チャートがあります。チャートはノードの主要なコンテンツとして理解でき、親と子は現在のノードの位置と関係を表し、それぞれ親ノードと子ノードを指す 2 つのポインターに似ています。
次のセクションでは、Ember-Data におけるモデルの関係を詳細に分析します。 -III. Ember-Data モデルの関連付け関係
Ember-Data は複数のデータ関係タイプをサポートします。これらの関係タイプは、データ側から返されるデータ型構造を期待するために使用されます。 次に、これらの API の役割を詳細に分析します。
Ember-Data リレーショナル モデルを理解する
注: 画像の 2 行目の OneToNone は、ここで作者がタイプミスをした可能性があります。
その中で、前のセクションで述べたように、Ember-Data には多くの規則があります。たとえば、定義された属性は Camel スタイルでなければならない (modelA など)、リスト配列の属性は s で終わる必要があります (など)。 modelAs として)、すべての ID は一意である必要があるため、サーバーから渡された JSON ハッシュ オブジェクトを読み取ると便利です。
Ember-Data エッジ (サイドロード) ローディングを理解する
まずモデルの定義を見てみましょう:
これは典型的な記事とコメントの構造です。つまり、記事には複数のコメントが含まれており、1 つのコメントは 1 つの記事に属します。
エッジローディングがどのように機能するかを見てみましょう:
このタイプのすべてのデータをリクエストすると、Ember-Data はウェアハウスにそのようなデータが存在しないことを検出し、サーバーへのリクエストを開始します。サーバーは記事のみを返します。コンテンツとコメント ID (コメントのすべての情報ではなく、コメントのプレビューのみを返すと理解できます)、コメントの詳細が再度要求されると、サーバーはコメントの実際の情報を返します。
初めてデータをリクエストするときに、サーバーにすべてのデータを返すようにできます: (コメントリクエストを待ってから返すのではなく)
注: このシナリオでは、ユーザーがコメントを表示しない場合、コメントは表示されません。これは、データが無意味にロードされる可能性があることを意味します。
もちろん、これはデータのシナリオによっても異なりますが、このモデルはより多くの HTTP リクエストを生成しますが、同時に返される「利用可能な」データの量を減らす必要があります。分析の選択方法には注意してください。もちろん、データを返す方法をカスタマイズすることもできます。
4. アダプターとシリアライザーをカスタマイズするここで、Ember はアダプターを書き換えるための 3 つの基本的なシナリオを提供します:
このシナリオを見てみましょう:
前のセクションのデータ型では、mainMenu には 1 対 1 のチャート タイプが含まれています。現在の要件は、チャートのタイムスパンを設定できることです。チャート データを部分的に取得する場合、設定されていない場合、デフォルトは 10 分です。
まず、DS.RESTAdapter から型を拡張し、アダプターの命名規則に従います (XXXXAdapter はこのパターンに従う必要があります)。
その後、次のメソッドを書き換えることができます:
現在のニーズでは、HTTP リクエストを作成する find() メソッドを書き換えるだけで済みます。
その中で重要なのは、Timespanを使ってhttpリクエストを再編成することで、目的は達成されました。
詳細については、http://guides.emberjs.com/v1.11.0/models/customizing-adapters/
RESTSerializer と比較して、次の非標準データ モデルを提供します。
この戻り値の型では、user_name、account_name、user_role は RESTSerializer に関連する非標準データです。また、最上位の属性名 user_model が一致しません。
目標を達成するために、アダプター内のメソッドを書き換えることができます:
ここでは、user_name、account_name、user_role の非標準化問題を解決するために Normalize メソッドを書き換える必要があり、user_model を解決するために typeForRoot メソッドを書き直す必要があります。問題。
アダプターの ULR アクセス タイプと変換定義をカスタマイズできます。良い例を次に示します。
最終的に次の URL にアクセスします: http://api.myapp.com/json/ v1/ mainMenus
FAQStore はデータを自動的にキャッシュし、id 属性を通じてデータの同一性を維持できます。また、ユーザーはフィルターを使用して不要なデータをフィルターできるようになります。
store.find() を使用すると、データによって RecordArray が自動的に更新され、RecordArray 上の計算されたプロパティまたはリスナーが通知されます。リクエストする必要がなく、データをロードしたい場合は、Store.push または PushPayload を使用してデータをストアにプッシュし、ストアでもリッスン イベントがトリガーされるようにすることができます。 SSE または WebSocket シナリオなど。
引用Ember-Data変更ログ: https://github.com/emberjs/data/blob/master/TRANSITION.md
参考文献: "Ember.js In Action"