18

JavaScript では、オブザーバー パターンが頻繁に使用されます。それには 1 つのトリッキーなことがあります。クリーンアップが必要です。通常のアプリケーションでは、次の経験則を使用します。

  • 被験者の寿命が観察者よりも短い（または等しい）場合、私はただ行うことができますsubject.on('event', ...)
  • 被験者の寿命が観察者よりも長い場合、使用する必要がありますobserver.listenTo(subject, 'event', ...)

2 番目のケースでは、listenToはオブザーバーのライフサイクルを認識しており、オブザーバーが終了する時間になると自動的にリスナーを削除します。

常にアプリケーションの一部のみがアクティブな現代の SPA (Single Page Application) スタイルでは、これが非常に重要になります。これを、イベント ストリームの最適な候補であり、おそらく長寿命である Web ソケットと組み合わせると、これはさらに重要になります。

FRPでは、時間の経過とともに変化する値を表すイベントストリームのようなものを持っているので、私は（知らず知らずのうちに）多くのリスナーを作成しています。それぞれfilter、mapおよびflatMap(おそらくリスナーを使用して) 前のストリームに結び付けられた新しいストリームを作成します。

私の考えでは、これらのリスナーをいつどのように削除する必要があるかを判断するのは非常に難しいようです。この問題について最初に考えたのが私だとは想像できませんが、インターネット上でこれについて多くを見つけることができませんでした。

他の言語のいくつかのフレームワークが弱参照を使用しているのを見てきました。JavaScript には弱参照の概念がありません (ここでは WeakMap は使用できません)。あったとしても、ガベージ コレクションがいつ行われるかが不明なので、それは悪い考えのように思えます。

  • これは現在のフレームワークでどのように解決されていますか?
  • フレームワークはオブジェクトのライフサイクルに結び付いていますか? はいの場合：どのように？
4

1 に答える 1

12

RxJ では、Observerデフォルトで、それぞれが元のイベント ソースに個別のリスナーを持ちます。だから、あなたが持っているなら

var s = $('#textInput').keyupAsObservable()
s.subscribe(subscriber1);
s.map(function() {}).subscribe(subscriber2);

2 つのキーアップ リスナーがあります。ソースへの単一の接続を維持する.publish().refCount()ために使用できます。Observable

Bacon.js では、Observable は常にソースへの単一の接続を維持します。

どちらのライブラリでも、ソースへの接続は ( が追加されたときに) 遅延して作成されObserver、(最後の) オブザーバーが削除されると自動的に削除されます。したがって、リスナーを手動で管理する必要はありません。

ただし、 のsubject寿命が よりも長い場合Observer、オブザーバーが寿命の終了時にサブスクリプションを停止していることを確認する必要があります。そうしないと、リークが発生します。Observerライブラリにとって、あなたは単なる関数であるため、どちらのライブラリにもこれを管理する「魔法の」方法はありません。

個人的には、Observer の寿命を知らせるためにObservablecalledなどを作成してから、 I subscribe to にサブスクライブする代わりに、しばしば作成します。deathsubjectsubject.takeUntil(death)

Elm に関しては、イベント ネットワーク全体を一度にセットアップしたので、リークの可能性はないと理解しています。Observers後から追加することはできません。

于 2014-11-04T11:48:37.437 に答える