2014-09-23 5 views
2

я следующее сообщение об ошибке:Ошибка: Digest уже Прогресс

Error: [$rootScope:inprog] $digest already in progress http://errors.angularjs.org/1.2.16/ $rootScope/inprog?p0=%24digest

Не совсем уверен, что корень этой проблемы или что именно это означает или то, что фазы «применить» или «переварить» означает? Я прочитал страницу и понять, что применить/дайджест вызывается область видимости объектов и

element.on('mouseup', function() { 
scope.$apply(function() { 
$scope.doStuff(); 
}); 
}); 

становится:

$apply = function(fn) { 
try { 
    fn(); 
} finally() { 
    $digest(); 
} 
} 
+0

Показать код – felipekm

ответ

1

Это может произойти, если вы звоните $scope.apply в то время как функция digest вызываются. Значение и, скорее всего, ваш scope.apply не требуется.

From Angular Docs: $digest() Processes all of the watchers of the current scope and its children. Usually, you don't call $ digest() directly in controllers or in directives.

Angular keeps track of what phase of processing we are in, the relevant ones being $apply and $digest. Trying to reenter a $digest or $apply while one of them is already in progress is typically a sign of programming error that needs to be fixed. So Angular will throw this error when that occurs. Click Here for more details

Ваш код напоминает старый трюк, который должен был быть реализован в более ранних версиях угловой (0,4 или 0,8), но насколько отзывом не требуется в версии угловой, который вы используете.

отметить также, что Угловая команда предложила нам способ diagnose this type of errors:

Когда вы получите эту ошибку он может быть достаточно сложной, чтобы диагностировать причину проблемы. Лучший способ действий - исследовать трассировку стека из ошибки. Вам нужно искать места, где $ apply или $ digest были вызваны, и найти контекст, в котором это произошло.

Там должно быть два вызова:

Первый вызов является хорошим $ применять/$ перевариваются и, как правило, вызванное некоторым событием в верхней части стека вызовов.

Второй звонок - это плохой $ apply/$ digest, и это тот, который нужно исследовать.

Как только вы определили этот вызов, вы прокладываете себе путь к стеку, чтобы узнать, в чем проблема.

Если второй вызов был выполнен в коде приложения, вы должны посмотреть, почему этот код был вызван из $ apply/$ digest. Это может быть простой надзор или, возможно, он соответствует сценарию sync/async, описанному ранее.

Если второй вызов был выполнен внутри Угловой директивы, то вполне вероятно, что он совпадает со вторым сценарием запуска программных событий, описанным ранее. В этом случае вам, возможно, потребуется посмотреть вверх по дереву на то, что вызвало событие в первую очередь.

Смежные вопросы