0

ko.mapping ユーティリティを使用してモデルをセットアップしています。

プライマリ データを渡すときは、プロパティの 1 つを配列と見なします。この配列は 1 週間の 7 日ごとに 1 つのオブジェクトであるため、このセットは変更も再配置もされないことがわかっています。フラット化されたプロパティを持つ JSON オブジェクトのコピーとして、または観察されたプロパティまたはフラットなプロパティを持つ observableArray として、この配列を簡単に生成できますが、マッピング ユーティリティを介してできないように見えるのは、以下を組み合わせたフラットな配列を作成することです基本特性と観測特性の両方。

マッピングオプションのさまざまな順列を試みましたが、この複雑なモデルを思い通りに正確にマッピングしたいという私の絶え間ない肛門の衝動を噛むことなく、この配列をマッピングする必要があるかのように見えますマップします。

問題をより適切に表示するには:

var PrimaryViewModelMapping = {
    copy: ['KeyProperty', 'ArrayOfDays'],
    create: function(options) { return new PrimaryViewModel(options.data); }
}

これにより、PrimaryViewModel のインスタンスで配列のフラット コピーが得られますが、PrimaryViewModel の宣言で配列をループして何かを実行することなく、ArrayOfDays 内のプロパティを制御することはできません。

続ける：

var PrimaryViewModelMapping = {
    copy: ['KeyProperty'],
    observe: ['ArrayOfDays'],
    create: function(options) { return new PrimaryViewModel(options.data); }
}

これにより、ArrayOfDays が監視可能な配列として適切にパッケージ化されますが、その「各」プロパティはすべてフラット化されたままになります。

次の試みは次のとおりです。

var PrimaryViewModelMapping = {
    copy: ['KeyProperty'],
    'ArrayOfDays': {
        copy: ['Date'],
        observe: ['TotalDuration'],
        create: function(options) {
            return new DayArrayModel(options.data);
        }
    }
}

これにより、観測可能な配列が作成され、観測されるもの (TotalDuration) と観測されないもの (KeyProperty) を完全に制御できるようになり、オブジェクト DayArrayModel の宣言内で、他にやりたいことがほぼ何でもできます...

しかし、ArrayOfDays はまだ監視可能な配列です。私はそれを必要としませんし、本当にしたくもありません。

ここでのトピックはマッピング プラグインに固有のものであり、これを処理するために PrimaryViewModel 宣言内でループを作成したくないことを理解してください。「機能要求」に出くわしたのか、それとも単にそれを取得していないのか疑問に思っています.

ありがとう。

4

2 に答える 2

0

Knockout のマッピングの話題で壁にぶつかりました。私はこの壁を登りましたが、当惑したままです。高度なユース ケースの観点から見ると、マッピング プラグインは、データと Knockout によってバインドされた viewModel の間の接続を難読化するだけのように見えます。

http://www.coderenaissance.com/から以下のリスト (およびコメントを追加)を発見しました。これには、まだあまり注目されていないように見えるマッピング プラグインの別のバリエーションがあるようです。私自身の経験とうまく調和しているので、私は作成者の洞察が好きです...

  • 大きなビュー モデル、特に古いブラウザー (IE7/8) や大規模な配列では遅くなりました。（大したことではない…まだ）
  • ビューモデルの作成はワンステップのプロセスではありませんでした... マッピングを呼び出した後、ビューモデルをさらに拡張する必要があります。 (場合によっては、小さなストレージ モデルの場合、これを行う必要はありませんでしたが、追加のプロパティ/関数については、既存のパターンに従い続ける必要がありました。)
  • これは、大きなビューモデルで問題となるビューモデル作成コードを整理する簡単な方法を提供しませんでした。(私の最大の悩みの 1 つは、プロパティの繰り返しを減らすことができるマッピング オプションの組み合わせを使用することを本当に望んでいたことです)
  • ビューモデルの作成方法をあまりカスタマイズできず、どのカスタマイズが混乱し、直感的に使用できませんでした。(ビューモデルの操作は絶対に避けられませんでした。マッピング手順のタイミング/順序は、私が望んでいたほど常に予測可能ではありませんでした。マッピングを一緒にカスケードし始めると、本当に混乱します。)

それで、私の最初の質問のオチは...または冗談ですが、今私には思えますが...スプーンがないということです。調査結果の結果、ko.mapping をスキーマの初期化として使用する試みを削除し、ko.applybindings コマンドの前にビューから初期トリガーを準備するためだけに使用しました。この時点で、以前と同じように、arrayMap と observable(array) の組み合わせを使用してオブジェクトを埋めます。今のところ、マッピング プラグインを使用しない場合についての知識を得ました。

于 2013-11-05T19:45:39.007 に答える