Warum würde $ q eine Weile dauern, um zu lösen

Question

Ich schreibe ein AngularJS-Plugin für Umbraco und habe eine einfache Ansicht, Controller und Service erstellt. Aber aus irgendeinem Grund dauert mein Versprechen eine Weile.

Ich habe den integrierten $ Q-Dienst verwendet, um mein Versprechen zu erstellen und zurückzugeben, ich habe meine Variablen ausgeloggt und kann sehen, wann der asynchrone Dienst beendet wird, aber es gibt einen merklichen Zeitunterschied zwischen dem und der Auflösungsfunktion.

Ich habe seit der Entdeckung entdeckt, wie es auf Umbracos GetRemainingTimeout Service wartet, bevor es verrechnet wird.

Kann jemand erklären, warum das passieren könnte?

viewController.js

angular.module('umbraco') 
    .controller('JaywingAnalyticsHelper.ViewController', function ($scope, googleService) { 
    googleService.checkAuth().then(function (signedIn){ 
     $scope.isAuthorised = signedIn; 
     console.log(signedIn); 
    }); 
    }); 

googleService.js

angular.module("umbraco") 
    .service('googleService', function ($q) { 

    var clientId = 'REMOVED_FOR_PRIVACY', 
     scopes = ['https://www.googleapis.com/auth/analytics.readonly'], 
     deferred = $q.defer(); 

    this.checkAuth = function() { 
     gapi.load('auth2', function() { 
     gapi.auth2.init().then(function() { 
      var googleAuth = gapi.auth2.getAuthInstance(); 
      var signedIn = googleAuth.isSignedIn.get(); 
      console.log(signedIn); 
      deferred.resolve(signedIn); 
     }, function(){ 
      deferred.reject(false); 
     }); 
     }); 

     return deferred.promise; 
    }; 
    }); 

Umbraco Version - 7.5.12
abgewinkelte Ausführung - 1.1.5

Answer 1

Nach einiger Zeit finden, um Ich habe den Grund für den Grund entdeckt, warum das Versprechen so war lange zu antworten.

meisten Endpunkte können mit Hilfe des $ http-Service innerhalb Winkel erreicht werden, aber gapi verwendet seine eigenen Methoden, um die Anfragen zu stellen und aufgrund der Winkellebenszyklus ist es wichtig, $ gelten aufzurufen, die zu Winkel auffordert Aktualisieren Sie alle Bindungen oder Beobachter.

zwei Links in der Dokumentation und andere große Ressource: https://code.angularjs.org/1.1.5/docs/api/ng.$rootScope.Scope#$apply http://jimhoskins.com/2012/12/17/angularjs-and-apply.html

Das war nervend einfach und kann nur auf meinen Mangel an Wissen Winkel verantwortlich gemacht werden. In meinem Fall wartete das Versprechen darauf, dass angular zu einem bestimmten Punkt in seinem Lebenszyklus kam, bevor es das Versprechen löste, anstatt es sofort zu aktualisieren. Ein Wrapping in der Apply-Funktion behebt dieses Problem.

$rootScope.$apply(function(){ 
    deferred.resolve(signedIn); 
}); 

Für Interessenten eine Reihe von Schritten war, die Diagnose dieser Frage führte mich, einschließlich:

• Bewegen des gapi Anruf aus dem Dienst und zurück in die Steuerung

  Dies hatte keine Wirkung, und das Versprechen dauerte noch eine Weile zu lösen.

• Vertauschen der gapi Forderung nach einem setTimeout aus

  Auch dies keine Wirkung hatte, und das Versprechen wurde noch während der Einnahme zu lösen, aber tat zeigen, dass das Problem nicht direkt verwandt war Gapi.

• mehrere setTimeouts unterschiedlicher Längen

  Dies war der nächste Schritt, wie es bewiesen hinzu, dass die Versprechen zugleich Lösung wurden, obwohl sie auseinander Sekunden sein sollte. Zwei wichtige Entdeckungen kamen daraus hervor. Interagieren mit der Ansicht veranlaßte die Versprechen zu lösen (eine Art von Lebenszyklus-Trigger) und dass es eine abgewinkelte Ausführung von setTimeout ist genannt $ timeout

• Lesen in warum

  $ timeout existiert

  Dies führte zu Erfahren Sie mehr über den eckigen Lebenszyklus und die $ apply-Funktion, warum und wann Sie es verwenden sollten. Problem gelöst.