AngularJS: Evite el error $ digest ya en progreso al llamar a $ scope. $ Apply ()

Estoy descubriendo que necesito actualizar mi página a mi alcance manualmente más y más desde la creación de una aplicación en angular.

La única forma en que sé hacer esto es llamar $apply()desde el alcance de mis controladores y directivas. El problema con esto es que sigue arrojando un error a la consola que dice:

Error: $ digest ya está en progreso

¿Alguien sabe cómo evitar este error o lograr lo mismo pero de una manera diferente?

No use este patrón : esto terminará causando más errores de los que resuelve. Aunque creas que solucionó algo, no lo hizo.

Puede verificar si a $digestya está en progreso al verificar $scope.$$phase.

if(!$scope.$$phase) {
  //$digest or $apply
}

$scope.$$phasevolverá "$digest"o "$apply"si a $digesto $applyestá en progreso. Creo que la diferencia entre estos estados es que $digestprocesará los relojes del alcance actual y sus hijos, y $applyprocesará a los observadores de todos los ámbitos.

Para el punto de @ dnc253, si te encuentras llamando $digesto con $applyfrecuencia, puedes estar haciéndolo mal. Generalmente encuentro que necesito digerir cuando necesito actualizar el estado del alcance como resultado de un evento DOM que se dispara fuera del alcance de Angular. Por ejemplo, cuando un modal de arranque de Twitter se oculta. A veces, el evento DOM se dispara cuando a $digestestá en progreso, a veces no. Por eso uso este cheque.

Me encantaría conocer una mejor manera si alguien conoce una.

De los comentarios: por @anddoutoi

Angular.js Anti Patrones

2. No lo hagas if (!$scope.$$phase) $scope.$apply(), significa que tu $scope.$apply()no es lo suficientemente alto en la pila de llamadas.

De una discusión reciente con los chicos de Angular sobre este mismo tema: por razones a prueba de futuro, no debes usar$$phase

Cuando se presiona para la forma "correcta" de hacerlo, la respuesta es actualmente

$timeout(function() {
  // anything you want can go here and will safely be run on the next digest.
})

Recientemente me encontré con esto al escribir servicios angulares para envolver las API de Facebook, Google y Twitter que, en diversos grados, reciben devoluciones de llamadas.

Aquí hay un ejemplo desde dentro de un servicio. (En aras de la brevedad, el resto del servicio, que configuró variables, inyectó $ timeout, etc., se ha dejado).

window.gapi.client.load('oauth2', 'v2', function() {
    var request = window.gapi.client.oauth2.userinfo.get();
    request.execute(function(response) {
        // This happens outside of angular land, so wrap it in a timeout 
        // with an implied apply and blammo, we're in action.
        $timeout(function() {
            if(typeof(response['error']) !== 'undefined'){
                // If the google api sent us an error, reject the promise.
                deferred.reject(response);
            }else{
                // Resolve the promise with the whole response if ok.
                deferred.resolve(response);
            }
        });
    });
});

Tenga en cuenta que el argumento de retraso para $ timeout es opcional y su valor predeterminado será 0 si no se establece ( $ timeout llama a $ browser.defer, que por defecto es 0 si no se establece el retraso )

Un poco no intuitivo, pero esa es la respuesta de los chicos que escriben Angular, ¡así que es lo suficientemente bueno para mí!

El ciclo de resumen es una llamada síncrona. No cederá el control al bucle de eventos del navegador hasta que termine. Hay algunas formas de lidiar con esto. La forma más fácil de lidiar con esto es usar el tiempo de espera incorporado de $, y una segunda forma es si está usando subrayado o lodash (y debería hacerlo), llame al siguiente:

$timeout(function(){
    //any code in here will automatically have an apply run afterwards
});

o si tienes lodash:

_.defer(function(){$scope.$apply();});

Intentamos varias soluciones y odiamos inyectar $ rootScope en todos nuestros controladores, directivas e incluso algunas fábricas. Entonces, $ timeout y _.defer han sido nuestros favoritos hasta ahora. Estos métodos le dicen a angular que espere hasta el próximo ciclo de animación, lo que garantizará que el alcance actual. $ Apply haya terminado.

Muchas de las respuestas aquí contienen buenos consejos, pero también pueden generar confusión. Simplemente usar no$timeout es la mejor solución ni la mejor. Además, asegúrese de leer eso si le preocupan las actuaciones o la escalabilidad.

Cosas que deberías saber

• $$phase es privado para el marco y hay buenas razones para ello.

• $timeout(callback)esperará hasta que se complete el ciclo de resumen actual (si lo hay), luego ejecutará la devolución de llamada, luego se ejecutará al final un completo $apply.

• $timeout(callback, delay, false)hará lo mismo (con un retraso opcional antes de ejecutar la devolución de llamada), pero no activará un $apply(tercer argumento) que ahorre actuaciones si no modificó su modelo Angular ($ scope).

• $scope.$apply(callback)invoca, entre otras cosas, lo $rootScope.$digestque significa que redirigirá el alcance raíz de la aplicación y todos sus elementos secundarios, incluso si está dentro de un alcance aislado.

• $scope.$digest()simplemente sincronizará su modelo con la vista, pero no asimilará el alcance de sus padres, lo que puede ahorrar muchas interpretaciones al trabajar en una parte aislada de su HTML con un alcance aislado (principalmente de una directiva). $ digest no recibe una devolución de llamada: ejecuta el código y luego resume.

• $scope.$evalAsync(callback)se ha introducido con angularjs 1.2 y probablemente resolverá la mayoría de sus problemas. Consulte el último párrafo para obtener más información al respecto.

• si obtienes el $digest already in progress error, entonces tu arquitectura está equivocada: o no necesitas rediseñar tu alcance, o no deberías estar a cargo de eso (ver más abajo).

Cómo estructurar tu código

Cuando recibe ese error, está tratando de digerir su alcance mientras ya está en progreso: dado que no conoce el estado de su alcance en ese momento, no está a cargo de lidiar con su digestión.

function editModel() {
  $scope.someVar = someVal;
  /* Do not apply your scope here since we don't know if that
     function is called synchronously from Angular or from an
     asynchronous code */
}

// Processed by Angular, for instance called by a ng-click directive
$scope.applyModelSynchronously = function() {
  // No need to digest
  editModel();
}

// Any kind of asynchronous code, for instance a server request
callServer(function() {
  /* That code is not watched nor digested by Angular, thus we
     can safely $apply it */
  $scope.$apply(editModel);
});

Y si sabe lo que está haciendo y trabajando en una pequeña directiva aislada mientras forma parte de una gran aplicación Angular, podría preferir $ digest en lugar de $ aplicar para guardar actuaciones.

Actualización desde Angularjs 1.2

Un nuevo método, de gran alcance ha sido añadido a cualquier ámbito $: $evalAsync. Básicamente, ejecutará su devolución de llamada dentro del ciclo de resumen actual si está ocurriendo uno; de lo contrario, un nuevo ciclo de resumen comenzará a ejecutar la devolución de llamada.

Todavía no es tan bueno como $scope.$digestsi realmente supiera que solo necesita sincronizar una parte aislada de su HTML (ya $applyque se activará una nueva si no hay ninguna en progreso), pero esta es la mejor solución cuando está ejecutando una función que no puede saber si se ejecutará sincrónicamente o no , por ejemplo, después de recuperar un recurso potencialmente almacenado en caché: a veces esto requerirá una llamada asíncrona a un servidor; de lo contrario, el recurso se recuperará localmente sincrónicamente.

En estos casos y en todos los demás donde tuvo un !$scope.$$phase, asegúrese de usar$scope.$evalAsync( callback )

Práctico método de ayuda para mantener este proceso SECO:

function safeApply(scope, fn) {
    (scope.$$phase || scope.$root.$$phase) ? fn() : scope.$apply(fn);
}

Tuve el mismo problema con scripts de terceros como CodeMirror, por ejemplo, y Krpano, e incluso el uso de los métodos safeApply mencionados aquí no me ha resuelto el error.

Pero lo que sí ha resuelto es usar el servicio $ timeout (no olvides inyectarlo primero).

Por lo tanto, algo como:

$timeout(function() {
  // run my code safely here
})

y si dentro de tu código estás usando

esta

quizás porque está dentro del controlador de una directiva de fábrica o simplemente necesita algún tipo de enlace, entonces haría algo como:

.factory('myClass', [
  '$timeout',
  function($timeout) {

    var myClass = function() {};

    myClass.prototype.surprise = function() {
      // Do something suprising! :D
    };

    myClass.prototype.beAmazing = function() {
      // Here 'this' referes to the current instance of myClass

      $timeout(angular.bind(this, function() {
          // Run my code safely here and this is not undefined but
          // the same as outside of this anonymous function
          this.surprise();
       }));
    }

    return new myClass();

  }]
)

Ver http://docs.angularjs.org/error/$rootScope:inprog

El problema surge cuando tiene una llamada $applyque a veces se ejecuta de forma asincrónica fuera del código angular (cuando se debe usar $ apply) y, a veces, sincrónicamente dentro del código angular (que causa el $digest already in progresserror).

Esto puede suceder, por ejemplo, cuando tiene una biblioteca que recupera asincrónicamente elementos de un servidor y los almacena en caché. La primera vez que se solicita un elemento, se recuperará de forma asincrónica para no bloquear la ejecución del código. La segunda vez, sin embargo, el elemento ya está en la memoria caché, por lo que puede recuperarse sincrónicamente.

La forma de evitar este error es asegurarse de que el código que llama $applyse ejecute de forma asincrónica. Esto se puede hacer ejecutando su código dentro de una llamada a $timeoutcon el retraso establecido en 0(que es el valor predeterminado). Sin embargo, llamar a su código adentro $timeoutelimina la necesidad de llamar $apply, porque $ timeout activará otro$digest ciclo por sí solo, lo que, a su vez, hará todas las actualizaciones necesarias, etc.

Solución

En resumen, en lugar de hacer esto:

... your controller code...

$http.get('some/url', function(data){
    $scope.$apply(function(){
        $scope.mydate = data.mydata;
    });
});

... more of your controller code...

hacer esto:

... your controller code...

$http.get('some/url', function(data){
    $timeout(function(){
        $scope.mydate = data.mydata;
    });
});

... more of your controller code...

Solo llamar $apply cuando sepa que el código en ejecución siempre se ejecutará fuera del código angular (por ejemplo, su llamada a $ apply se realizará dentro de una devolución de llamada que se llama por código fuera de su código angular).

A menos que alguien sea consciente de alguna desventaja impactante al usarlo en $timeoutexceso $apply, no veo por qué no siempre puede usarlo $timeout(con cero retraso) en lugar de hacerlo $apply, ya que hará aproximadamente lo mismo.

Cuando obtiene este error, básicamente significa que ya está en el proceso de actualizar su vista. Realmente no debería necesitar llamar $apply()dentro de su controlador. Si su vista no se actualiza como es de esperar, y luego recibe este error después de llamar $apply(), lo más probable es que no esté actualizando el modelo correctamente. Si publica algunos detalles, podríamos resolver el problema central.

La forma más corta de caja fuerte $applyes:

$timeout(angular.noop)

También puede usar evalAsync. ¡Funcionará en algún momento después de que el resumen haya terminado!

scope.evalAsync(function(scope){
    //use the scope...
});

Antes que nada, no lo arregles de esta manera

if ( ! $scope.$$phase) { 
  $scope.$apply(); 
}

No tiene sentido porque $ phase es solo una bandera booleana para el ciclo de $ digest, por lo que su $ apply () a veces no se ejecutará. Y recuerda que es una mala práctica.

En cambio, use $timeout

    $timeout(function(){ 
  // Any code in here will automatically have an $scope.apply() run afterwards 
$scope.myvar = newValue; 
  // And it just works! 
});

Si está usando subrayado o lodash, puede usar defer ():

_.defer(function(){ 
  $scope.$apply(); 
});

A veces, aún obtendrá errores si lo usa de esta manera ( https://stackoverflow.com/a/12859093/801426 ).

Prueba esto:

if(! $rootScope.$root.$$phase) {
...

Debe usar $ evalAsync o $ timeout según el contexto.

Este es un enlace con una buena explicación:

http://www.bennadel.com/blog/2605-scope-evalasync-vs-timeout-in-angularjs.htm

intenta usar

$scope.applyAsync(function() {
    // your code
});

en vez de

if(!$scope.$$phase) {
  //$digest or $apply
}

$ applyAsync Programe la invocación de $ apply para que ocurra más adelante. Esto se puede usar para poner en cola múltiples expresiones que deben evaluarse en el mismo resumen.

NOTA: Dentro de $ digest, $ applyAsync () solo se vaciará si el alcance actual es $ rootScope. Esto significa que si llama a $ digest en un ámbito secundario, no vaciará implícitamente la cola $ applyAsync ().

Ejemplo:

  $scope.$applyAsync(function () {
                if (!authService.authenticated) {
                    return;
                }

                if (vm.file !== null) {
                    loadService.setState(SignWizardStates.SIGN);
                } else {
                    loadService.setState(SignWizardStates.UPLOAD_FILE);
                }
            });

Referencias

1. Scope. $ ApplyAsync () vs. Scope. $ EvalAsync () en AngularJS 1.3

2. AngularJs Docs

Le aconsejaría que use un evento personalizado en lugar de desencadenar un ciclo de resumen.

He llegado a la conclusión de que transmitir eventos personalizados y registrar oyentes para estos eventos es una buena solución para activar una acción que desea que se produzca, esté o no en un ciclo de resumen.

Al crear un evento personalizado, también está siendo más eficiente con su código porque solo activa los oyentes suscritos a dicho evento y NO activa todos los relojes vinculados al alcance como lo haría si invocara el alcance. $ Apply.

$scope.$on('customEventName', function (optionalCustomEventArguments) {
   //TODO: Respond to event
});


$scope.$broadcast('customEventName', optionalCustomEventArguments);

yearofmoo hizo un gran trabajo al crear una función reutilizable $ safeApply para nosotros:

https://github.com/yearofmoo/AngularJS-Scope.SafeApply

Uso:

//use by itself
$scope.$safeApply();

//tell it which scope to update
$scope.$safeApply($scope);
$scope.$safeApply($anotherScope);

//pass in an update function that gets called when the digest is going on...
$scope.$safeApply(function() {

});

//pass in both a scope and a function
$scope.$safeApply($anotherScope,function() {

});

//call it on the rootScope
$rootScope.$safeApply();
$rootScope.$safeApply($rootScope);
$rootScope.$safeApply($scope);
$rootScope.$safeApply($scope, fn);
$rootScope.$safeApply(fn);

He podido resolver este problema llamando en $evallugar de $applyen lugares donde sé que la $digestfunción se ejecutará.

Según los documentos , $applybásicamente hace esto:

function $apply(expr) {
  try {
    return $eval(expr);
  } catch (e) {
    $exceptionHandler(e);
  } finally {
    $root.$digest();
  }
}

En mi caso, un ng-clickcambia una variable dentro de un ámbito, y un $ watch en esa variable cambia otras variables que tienen que ser $applied. Este último paso provoca el error "resumen ya en progreso".

Al reemplazar $applycon$eval dentro de la expresión de observación, las variables de alcance se actualizan como se esperaba.

Por lo tanto, parece que si el resumen se va a ejecutar de todos modos debido a algún otro cambio dentro de Angular, $evaling es todo lo que necesita hacer.

utilizar $scope.$$phase || $scope.$apply();en su lugar

La comprensión de que los documentos angular llaman comprobar el $$phaseun anti-patrón , traté de conseguir $timeouty_.defer de trabajo.

El tiempo de espera y los métodos diferidos crean un destello de {{myVar}}contenido no analizado en el dom como un FOUT . Para mí esto no era aceptable. Me deja sin mucho que decir dogmáticamente que algo es un truco y no tiene una alternativa adecuada.

Lo único que funciona cada vez es:

if(scope.$$phase !== '$digest'){ scope.$digest() }.

No entiendo el peligro de este método, o por qué es descrito como un hack por personas en los comentarios y el equipo angular. El comando parece preciso y fácil de leer:

"Haz el resumen a menos que ya esté sucediendo uno"

En CoffeeScript es aún más bonito:

scope.$digest() unless scope.$$phase is '$digest'

¿Cuál es el problema con esto? ¿Hay alguna alternativa que no cree un FOUT? $ safeApply se ve bien pero también usa el $$phasemétodo de inspección.

Este es mi servicio de utilidades:

angular.module('myApp', []).service('Utils', function Utils($timeout) {
    var Super = this;

    this.doWhenReady = function(scope, callback, args) {
        if(!scope.$$phase) {
            if (args instanceof Array)
                callback.apply(scope, Array.prototype.slice.call(args))
            else
                callback();
        }
        else {
            $timeout(function() {
                Super.doWhenReady(scope, callback, args);
            }, 250);
        }
    };
});

y este es un ejemplo de su uso:

angular.module('myApp').controller('MyCtrl', function ($scope, Utils) {
    $scope.foo = function() {
        // some code here . . .
    };

    Utils.doWhenReady($scope, $scope.foo);

    $scope.fooWithParams = function(p1, p2) {
        // some code here . . .
    };

    Utils.doWhenReady($scope, $scope.fooWithParams, ['value1', 'value2']);
};

He estado usando este método y parece funcionar perfectamente bien. Esto solo espera el tiempo que el ciclo ha terminado y luego se dispara apply(). Simplemente llame a la función apply(<your scope>)desde cualquier lugar que desee.

function apply(scope) {
  if (!scope.$$phase && !scope.$root.$$phase) {
    scope.$apply();
    console.log("Scope Apply Done !!");
  } 
  else {
    console.log("Scheduling Apply after 200ms digest cycle already in progress");
    setTimeout(function() {
        apply(scope)
    }, 200);
  }
}

Cuando desactivé el depurador, el error ya no ocurre. En mi caso , fue porque el depurador detuvo la ejecución del código.

similar a las respuestas anteriores, pero esto ha funcionado fielmente para mí ... en un servicio agregue:

    //sometimes you need to refresh scope, use this to prevent conflict
    this.applyAsNeeded = function (scope) {
        if (!scope.$$phase) {
            scope.$apply();
        }
    };

Puedes usar

$timeout

para evitar el error

 $timeout(function () {
                        var scope = angular.element($("#myController")).scope();
                        scope.myMethod();
                        scope.$scope();
                    },1);

Básicamente, el problema surge cuando, estamos solicitando angular para ejecutar el ciclo de resumen, aunque está en proceso, lo que está creando un problema angular para la comprensión. consecuencia excepción en consola.
1. No tiene ningún sentido llamar a scope. $ Apply () dentro de la función $ timeout porque internamente hace lo mismo.
2. El código va con la función JavaScript vainilla porque su definición angular no angular es nativa, es decir, setTimeout
3. Para ello, puede utilizar

if (!
Scope . $$ phase) { scope. $ EvalAsync (function () {

}); }

        let $timeoutPromise = null;
        $timeout.cancel($timeoutPromise);
        $timeoutPromise = $timeout(() => {
            $scope.$digest();
        }, 0, false);

Aquí hay una buena solución para evitar este error y evitar $ apply

puede combinar esto con debounce (0) si llama en función de un evento externo. Arriba está el 'rebote' que estamos usando, y un ejemplo completo de código

.factory('debounce', [
    '$timeout',
    function ($timeout) {

        return function (func, wait, apply) {
            // apply default is true for $timeout
            if (apply !== false) {
                apply = true;
            }

            var promise;
            return function () {
                var cntx = this,
                    args = arguments;
                $timeout.cancel(promise);
                promise = $timeout(function () {
                    return func.apply(cntx, args);
                }, wait, apply);
                return promise;
            };
        };
    }
])

y el código en sí para escuchar algún evento y llamar a $ digest solo en $ scope que necesita

        let $timeoutPromise = null;
        let $update = debounce(function () {
            $timeout.cancel($timeoutPromise);
            $timeoutPromise = $timeout(() => {
                $scope.$digest();
            }, 0, false);
        }, 0, false);

        let $unwatchModelChanges = $scope.$root.$on('updatePropertiesInspector', function () {
            $update();
        });


        $scope.$on('$destroy', () => {
            $timeout.cancel($update);
            $timeout.cancel($timeoutPromise);
            $unwatchModelChanges();
        });

Encontré esto: https://coderwall.com/p/ngisma donde Nathan Walker (cerca de la parte inferior de la página) sugiere un decorador en $ rootScope para crear el func 'safeApply', código:

yourAwesomeModule.config([
  '$provide', function($provide) {
    return $provide.decorator('$rootScope', [
      '$delegate', function($delegate) {
        $delegate.safeApply = function(fn) {
          var phase = $delegate.$$phase;
          if (phase === "$apply" || phase === "$digest") {
            if (fn && typeof fn === 'function') {
              fn();
            }
          } else {
            $delegate.$apply(fn);
          }
        };
        return $delegate;
      }
    ]);
  }
]);

Esto resolverá tu problema:

if(!$scope.$$phase) {
  //TODO
}