traite-t-Async complet comme prévu, même lorsque le composant est détruit

Question

J'ai un pop up modal, lorsque l'utilisateur clique sur soumettre dans le modal, il va à ma base de données et enregistre des données là-bas. Le modal est fermé après cela. Cependant, comme il s'agit d'un modal, l'utilisateur peut le fermer via le bouton ESC. Donc, je veux m'assurer que même si l'utilisateur appuie sur ESC, l'async se termine sans se couper au milieu.

Par exemple.

// from my modal component 
onSubmit() { 
    this.databaseService.saveToDatabase(data) 
     .first() 
     .subscribe(result => { 
      console.log('complete') 
      closeModal(); 
     }, error => { 
      console.log(error) 
     }) 
} 

ngOnDestroy() { 
    console.log('modal Desstroyed') 
} 

Pour l'exemple ci-dessus, si je pressais esc dès que je frappe soumettre, je vois de la console

modal Destroyed 

complete 

Cela donne à penser que mon arrivée d'appel async comme prévu ce qui est bon. Je l'ai trouvé bizarre si ..... pourquoi Angular 2 ne s'est pas accroché au composant jusqu'à ce que le processus asynchrone se termine. Comment ma finition fonction onSubmit même si le composant a été détruit (en supposant que ce qui arrive quand ngOnDestry() est appelée). Dans un autre langage tel que Swift, le contrôleur de vues n'est pas détruit tant que tout le processus n'est pas terminé (sauf si vous le spécifiez pour être détruit). est beaucoup plus long comme le suivant. Vais-je arriver encore «2ème étape complète si je ferme le modal immédiatement après avoir appuyé sur le bouton soumettre

// from my modal component 
onSubmit() { 
    this.databaseService.saveToDatabase(data) 
     .first() 
     .subscribe(result => { 
      console.log('complete 1st stage') 
      this.databaseService.saveToDatabase(reult) 
       .first() 
       .subscribe(result => { 
        console.log('2nd stage complete') 
        closeModal(); 
       }) 
     }) 
} 

Answer 1

Je ne parlerai pas de JS asynchronisme comme il a été couvert autour de débordement de pile et de nombreux site tutoriel, etc. Je vais juste parler des Observables et de la gestion des abonnements.

La première chose à savoir est « ça dépend ». Cela dépend de la manière dont votre Observable est créé et de la façon dont vous gérez votre abonnement.

lorsque vous créez un Observable avec Observable.create vous définissez ce qu'il faut faire lorsque vous vous désabonnez. Dans cet exemple, l'intervalle est arrêté lorsque vous vous désabonnez:

let foo = Observable.create((observer)=>{ 
    // this is called when an observer subscribe to this Observable 
    let interval = setInterval(()=>{ 
    observer.next("foo"); 
    }); 
    // returns what to do on unsubscribe... 
    return()=>{ 
    clearInterval(interval); 
    } 
}); 
let sub = foo.subscribe(data=>console.log(data)); 
window.setTimeout(()=>sub.unsubscribe(),1000); // passed 1000ms, unsubscribe and cancel the interval... 

Par exemple, service angulaire Whit Http, une requête HTTP est annulée lorsque vous vous désabonnez à elle.

Bien que vous ne vous désabonnez pas de votre Observable et qu'il ne soit pas complete, il est toujours en cours d'exécution, que le composant soit détruit ou non.

Notez que c'est une bonne pratique à avoid multiple subscriptions, parce que lorsque vous gérez vos abonnements impérativement, vous n'avez pas les avantages d'utiliser RxJS. Il est donc préférable d'utiliser les opérateurs disponibles pour contrôler le flux de vos événements.