发表新帖
发表新帖

Is it necessary to unsubscribe from observables created by Http methods?

前端 未结
关注
9 1679
醉酒成梦
醉酒成梦 2020-11-22 04:50

Do you need to unsubscribe from Angular 2 http calls to prevent memory leak?

 fetchFilm(index) {
        var sub = this._http.get(`http://example.com`)
9条回答
  • -上瘾入骨i
    -上瘾入骨i (楼主)
    2020-11-22 05:11

    After a while of testing, reading documentation and the sourcecode of the HttpClient.

    HttpClient: https://github.com/angular/angular/blob/master/packages/common/http/src/client.ts

    HttpXhrBackend : https://github.com/angular/angular/blob/master/packages/common/http/src/xhr.ts

    HttpClientModule: https://indepth.dev/exploring-the-httpclientmodule-in-angular/

    Angular Univeristy: https://blog.angular-university.io/angular-http/

    This particular type of Observables are single-value streams: If the HTTP request is successful, these observables will emit only one value and then complete

    And the answer to the whole Issue of "do i NEED" to unsubscribe ?

    It depends. Http call Memoryleaks are not a issue. The issues are the logic in your callback functions.

    For example: Routing or Login.

    If your call is a login call, you don't have to "unsubscribe" but you need to make sure if the User leaves the page, you handle the response properly in the absence of the user. 

    
this.authorisationService
      .authorize(data.username, data.password)
      .subscribe((res: HttpResponse) => {
          this.handleLoginResponse(res);
        },
        (error: HttpErrorResponse) => {
          this.messageService.error('Authentication failed');
        },
        () => {
          this.messageService.info('Login has completed');
        })



    From annoying to dangerous
    


    Now just imagine, the network is slower than usual, the call takes longer 5 seconds, and the user leaves the login view and goes to a "support view" .
    


    The component may not be active but the subscription. In case of a response, the user will be suddenly rerouted (depending on your handleResponse() implementation).
    


    This is not good. 
    


    Also just imagine the user leaves the pc, believing he is not logged in yet. But you logic logs the user in, now you have a security issue. 
    


    What can you do WITHOUT unsubscribing?
    


    Make you call dependent on the current state of the view: 
    


      public isActive = false;
  public ngOnInit(): void {
    this.isActive = true;
  }

  public ngOnDestroy(): void {
    this.isActive = false;
  }


    


    User .pipe(takeWhile(value => this.isActive)) to make sure the response is only handled when the view is active. 
    


    
this.authorisationService
      .authorize(data.username, data.password).pipe(takeWhile(value => this.isActive))
      .subscribe((res: HttpResponse) => {
          this.handleLoginResponse(res);
        },
        (error: HttpErrorResponse) => {
          this.messageService.error('Authentication failed');
        },
        () => {
          this.messageService.info('Login has completed');
        })



    But how can you be sure that the subscription isn't causing memoryleaks ?
    


    You can log if the "teardownLogic" is applied. 
    


    The teardownLogic of a subscription will be called when the subcription is empty or unsubscribed. 
    


    
this.authorisationService
      .authorize(data.username, data.password).pipe(takeWhile(value => this.isActive))
      .subscribe((res: HttpResponse) => {
          this.handleLoginResponse(res);
        },
        (error: HttpErrorResponse) => {
          this.messageService.error('Authentication failed');
        },
        () => {
          this.messageService.info('Login has completed');
    }).add(() => {
        // this is the teardown function
        // will be called in the end
      this.messageService.info('Teardown');
    });




    You don't have to unsubscribe.
You should know if there are issues in your logic, that could cause Problems in your subscription. And take care of them. In the most cases, it won't be a issue, but especcialy at critical tasks like autorization, you should take care of unexpected behaviour, wether its with "unsubscribe" or a other logic like piping or conditional callback functions. 
    


    why not just always unsubscribe?
    


    Imagine you make a put or post request. The server recieves the message either way, just the response takes a while. Unsubscribing, won't undo the post or put. 
But when you unsubscribe, you won't have the chance to handle the response or inform the User, for example via Dialog or a Toast/Message etc. 
    


    Wich causes the User to believe, that the put/post request was not done. 
    


    So it depends. It is your design decision, how to deal with such issues. 
    
    
    
             
    
                                                        
    
            
            
    
              
                
                0
              
                   
                
               讨论(0)
              
                                                  
              
              
    
                          
             
       
          
              
    
                                       
    

    

                
    
                         
          
                              			
        
        
        
    
          
    
            
            
    
              
              
    
            
    


                                 
              
    
            
    
                          
    

        
         
    
                
                
    
                  
                
    
                
    
                   看不清?
                
    
              
    
                                  
    
                    
   
                 
             
              
    提交回复
    
            
    
          
    
        
    
      
       
      
    
    
    
          
 
     
 
    
        
    热议问题