1

私が混乱していることを示すために、2つのplunkrの準備ができています。最初の plunkr が失敗する正確な理由について明確な説明を求めていますが、2 番目の plunkr は機能します。

この最初の plunkr では、外部ライブラリの呼び出しをシミュレートして、ある種のネットワーク認証を行います。問題は、元のコントローラー レベル メソッドからのチェーンに 2 つのプロミスがある場合、解決時に実行するために最初のプロミスに渡された関数が起動せず、各プロミスを解決したにもかかわらず、チェーンのさらに下にある他のプロミスも実行されないことです。

http://plnkr.co/edit/6uKnVvEI3bJvfmaUoWN0

ただし、遅延をシミュレートするために使用されるか、実際の外部操作 (REST API の呼び出しなど) から返される deferred.resolve をラップするために使用されるかに関係なく、呼び出しを $timeout を使用するように変更すると、すべてが機能します。予想通り。この 2 番目の plunkr では、両方の deferred.resolve 呼び出しが $timeout 呼び出しでラップされるように変更されると、ログイン機能が問題なく動作することがわかります。

さらに、Promise を返す前に解決すると失敗するという問題として、他の誰かが提案したテスト ケースを含めました。この 2 番目の plunkr は正確にそれを行うときに問題なく動作するため、これは明らかに当てはまりません。この代替方法は $timeout を使用しませんが、問題なく機能することに注意してください。これは、2 つのサービス (testApi、authService) の間の関係に特別なものがあることを示しています。両方が promise オブジェクトを返し、その結果、ネストされた promise のチェーンが上向きに解決される必要があります。

http://plnkr.co/edit/xp8NeZKWDep6cPys5gJu?p=preview

これらの約束があるインスタンスでは失敗するが、ネストされていない場合、またはネストされている場合に別のインスタンスで機能する理由を説明できる人はいますか $timeout?

私の直感は、ダイジェスト サイクルに関連するものですが、私の人生では、ダイジェスト サイクルが、本質的にコントローラーから独立して実行されているサービスに影響を与える理由を理解できません。これらは、コントローラーがロードされる前に解決する必要がある $scope のプロパティではなく、promise を返すサービス呼び出しをラップする関数です。

4

1 に答える 1

3

あなたの勘は正しいです。を使用するsetTimeoutと、Angular が何も知らないイベントがトリガーされます。$timeout代わりに使用する場合はそうではありません。したがって、最初の Plunker スクリプトを機能させるには、次のように呼び出してダイジェスト サイクルを手動で開始する必要があります$rootScope.$apply()。

angular.module('testApi', []).factory('testApi', function($q, $rootScope) {
...    
    setTimeout(function() { 
        $rootScope.$apply(function() { 
            deferred.resolve({user: { id: '1', name: 'bozo'}}); 
        });
    }, 1000);

ここでプランカー。

に固執する場合、上記のいずれも行う必要はありません$timeout。そうすることをお勧めします。

This SO questionには、 $digest サイクルに入ったときにのみ promises コールバックが呼び出される理由に関する詳細情報があります。

于 2013-09-12T04:45:10.953 に答える