web-dev-qa-db-fra.com

Pourquoi devrais-je utiliser l'interrogation RxJS interval () ou timer () au lieu de window.setInterval ()?

Cas d'utilisation: Appelez une fonction toutes les minutes (60000 ms) qui envoie une action de magasin pour récupérer lastUpdated le statut des éléments, qui lors de la réponse et filtrage, met à jour le magasin et le magasin mis à jour est lu comme observable et affiché dans la vue). Cela doit se produire tant que l'application Web est ouverte (donc indéfiniment).

Actuellement, j'utilise ceci:

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

Et lorsque la vue est détruite/démontée, je supprime l'intervalle comme suit:

if (this.refreshDate) {
  clearInterval(this.refreshDate);
}

Est-ce efficace/efficace, ou est-ce gênant?

Pourquoi voudrais-je utiliser une stratégie d'interrogation RxJS comme:

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

Ou

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

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

Conclusion/réponses (pour faciliter la recherche):

Il y a un grand avantage à utiliser les fonctions RxJS pour définir un intervalle ou effectuer une interrogation, ces avantages sont expliqués dans réponse sélectionnée mais aussi dans les commentaires, mais il est conclu ( par des discussions dans les commentaires) que pour l'exigence très simple définie dans la section " Cas d'utilisation " au début de cet article, il n'est pas nécessaire d'utiliser RxJS, et en fait si vous n'utilisez RxJS dans aucune autre partie de votre programme, ne l'importez pas juste pour cela, cependant dans mon cas, j'avais déjà importé et utilisé RxJS ailleurs.

javascripttypescriptrxjsrxjs5rxjs6
12
msamprz

Avantage de RxJS:

Paresse

Vous pouvez créer vos observables et jusqu'à ce que vous appeliez subscribe rien ne se passe. Observable = fonction pure. Cela vous donne plus de contrôle, un raisonnement plus facile et permet le point suivant ...

Composabilité

Vous pouvez combiner interval/timer avec d'autres operators création d'une logique personnalisée très facilement de manière unifiée - par exemple vous pouvez map, repeat, retry, take ... etc. voir tous les opérateurs

Gestion des erreurs

En cas d'erreur, vous êtes responsable d'appeler clearTimeout/clearInterval - Les observables s'occupent de cela pour vous. Il en résulte un code plus propre et moins de bugs de fuite de mémoire .

Bien sûr, tout ce que vous faites avec Observables, vous pouvez également le faire sans Observables - mais ce n'est pas le but. Les observables sont là pour vous faciliter la vie.

Notez également que interval/timer ne sont pas de bonnes usines observables pour l'interrogation car elles n'attendent pas la fin de votre action asynchrone (vous pouvez vous retrouver avec plusieurs appels asynchrones s'exécutant les uns sur les autres). Pour cela, j'ai tendance à utiliser defer et repeatWhen comme ceci:

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

window.setInterval ne se soucie pas de votre état de rappel, il s'exécutera à l'intervalle donné malgré le statut de l'exécution précédente des rappels, et la seule façon de le faire s'arrêter et de sauter est d'effacer l'intervalle ou de le réinitialiser.

D'autre part, les solutions basées sur RxJS Observable (interval, timer) vous permettent de diriger des opérateurs conditionnels (takeWhile, skipWhile par exemple) qui vous permettent de ajoutez un arrêt ou implémentez une logique d'arrêt-démarrage en retournant simplement un indicateur booléen, au lieu d'ajouter une logique compliquée d'effacement de l'intervalle, puis de le recréer.

Et ce sont des observables, vous pouvez les écouter dans toute l'application et y attacher un nombre illimité d'écouteurs.

La gestion des erreurs est également meilleure, vous vous abonnez à tous les succès et gérez tout dans un rappel de capture.

1
Ashish Jhanwar