1

これは非常に一般的に議論されるトピックであることは知っていますが、私の質問に正確に答えるものは何も見つかりません:)

現在、Backbone.js プロジェクトに取り組んでいます。ルーターに関しては、ルーター内でビュー、モデル、またはコレクションをインスタンス化するのではなく、状態を処理する 1 つの方法としてルーターを使用します。ルーターはカスタム コントローラー オブジェクトのメソッドを呼び出します。

次に、コントローラーは、インデックス、ショーなどのさまざまなビュー、モデル、およびコレクションをインスタンス化します。これはすべてうまくいきます。

ページ遷移の処理方法に少し苦労しています。私はゾンビの管理などに関する素晴らしい投稿をすべて読みましたが、何が起こっても古いビューのクリーンアップ システムが必要であることを知っています (私は現在、Derick Bailey がブログで書いた .close() メソッドを使用しています)。

#show から #index へ、またはその他のルート変更を行う場合、新しい新鮮なビュー、モデルなどをインスタンス化するだけでよいことを理解しています。これは、ほぼすべてのチュートリアルで見られることです。もちろん、古いものを確実にクリーンアップします。

しかし、すでに #show を使用していて、別の #show ページにルーティングした場合、必要なすべてのビューなどは既にインスタンス化されてレンダリングされています。変更したいのは、モデルとコレクションのデータだけです。

ですから、私の質問は、人々がビューをあまり再利用していないのはなぜだと思いますか。私の頭の中で、あなたがすでにあなたが望むページにいるなら、そのビューがリンクされているモデル/コレクションの url または urlRoot を更新して再取得する方が理にかなっているだろうと考えていました。これにより、リセット イベントがトリガーされ、必要なすべてのビューがこれにサブスクライブして、自分自身を再レンダリングできます。

しかし、私が言うように、私は人々がこれをしているのを見ません. それは本当に悪い考えだからですか?誰かがこのようなことをしている場合、「更新可能な」モデルとコレクションの追跡にどのように対処しますか?

ありがとう!

4

1 に答える 1

2

ビューの使用方法と、ビューの複雑さ/大きさに大きく依存すると思います。

ビューが非常に単純な場合は、ビュー全体を再レンダリングして既存の HTML を新しいマークアップに置き換える方が簡単な場合がよくあります (必要な部分を変更するために DOM をトラバースするよりも高速な場合もあります。ただし、より複雑なビューの場合は、変更される情報はごくわずかであり、適切な属性変更イベント (例: _bind('change:name', this.nameChanged,this))をリッスンしてから、DOM のその部分のみを更新する方がよいでしょう。

規則ではrender要素をレンダリングするメソッドを使用することですが、追加の更新イベントをrefresh特定の部分にのみ簡単に適用でき、モデルを交換して (@jackwanders が提案したように)refreshメソッドを呼び出すことができることに注意してください。

于 2012-07-05T18:24:19.017 に答える