web-dev-qa-db-ja.com

window.setInterval（）の代わりにRxJS interval（）またはtimer（）ポーリングを使用するのはなぜですか？

ユースケース：ストアアクションをディスパッチする関数を毎分（60000ミリ秒）呼び出して、アイテムのlastUpdatedステータスを取得します。フィルタリング、ストアの更新、更新されたストアはオブザーバブルとして読み取られ、ビューに表示されます）。これは、Webアプリが開いている限り（つまり無期限に）発生する必要があります。

現在、私はこれを使用しています：

_this.refreshDate = window.setInterval(
  () => this.store.dispatch(new FetchLastUpdate())
, 60000);
_

そして、ビューが破棄/マウント解除されると、間隔を削除します：

_if (this.refreshDate) {
  clearInterval(this.refreshDate);
}
_

これは効率的/効果的ですか、それとも面倒ですか？

なぜ次のようなRxJSポーリング戦略を使用したいのですか？

_interval(60000)
  .pipe(
    startWith(0),
    switchMap(() => this.store.dispatch(new FetchLastUpdate()))
   );
_

または

_timer(0, 60000)
  .pipe(
    switchMap(() => this.store.dispatch(new FetchLastUpdate()))
  );
_

TL; DR：window.setInterval() vs. RxJS timer()/interval()

結論/回答（調査を容易にするため）：

RxJS関数を使用して間隔を設定したりポーリングを実行したりすることには大きな利点があります。これらの利点は selected answer で説明されていますが、 （コメントでの議論により）この投稿の冒頭の「ユースケース」セクションで定義されている非常に単純な要件については、 RxJSを使用する必要はありません。実際、プログラムの他の部分でRxJSを使用していない場合は、これだけのためにインポートしないでください。ただし、私の場合は、RxJSを既にインポートして使用しています。

javascripttypescriptrxjsrxjs5rxjs6
12
msamprz

RxJSの利点：

怠azine

Observablesを作成し、subscribeを呼び出すまで何も起こりません。観測可能=純粋な関数。これにより、より制御しやすく、推論が容易になり、次のポイントが可能になります.

構成可能性

interval/timerを他のoperatorsと組み合わせて、統一された方法で非常に簡単にカスタムロジックを作成できます。たとえば、map、repeat、retry、 take...など すべての演算子を参照

エラー処理

エラーが発生した場合、clearTimeout/clearIntervalを呼び出す必要があります-オブザーバブルがこれを処理します。結果として、よりクリーンなコードと少ないメモリリークバグが発生します。

もちろん、Observablesを使用して行うことは、Observablesを使用せずに行うこともできますが、それはポイントではありません。あなたの人生を楽にするためにオブザーバブルがここにあります。

また、interval/timerは、非同期アクションが終了するまで「待機」しないため、ポーリングに適した監視可能なファクトリではないことに注意してください（複数の非同期呼び出しが相互に実行される可能性があります）。そのために、私はdeferとrepeatWhenを次のように使用する傾向があります。

defer(() => doAsyncAction())
  .pipe(
    repeatWhen(notifications => notifications.pipe(delay(1234)))
  );
13
m1ch4ls

window.setIntervalは、コールバックの状態を気にしません。過去のコールバックの実行状態にかかわらず、指定された間隔で実行されます。停止してスキップする唯一の方法は、間隔をクリアするか再初期化することです。

一方、RxJS Observableベースのソリューション（interval、timer）を使用すると、条件付き演算子（たとえば[takeWhile、skipWhile）をパイプ処理できます。インターバルをクリアしてから再作成する複雑なロジックを追加する代わりに、ブールフラグを反転するだけでストップを追加するか、ストップスタートロジックを実装します。

そして、それらはオブザーバブルであり、アプリケーション全体でそれらをリッスンし、任意の数のリスナーをアタッチできます。

エラー処理も優れています。すべての成功をサブスクライブし、キャッチコールバックですべてを処理します。

1
Ashish Jhanwar