Caso de esquina interesante ... http://plnkr.co/edit/lsrga8qMcbgNWATrVht3?p=preview

Esto sucede solo cuando la función onChange se delega al ancho del alcance principal del enlace '&'.

Hemos estado trabajando en una herramienta RAD basada en angularjs.
Este fue un error importante ya que todos los widgets de la aplicación tienen isolateScope.
Hemos resuelto el problema creando un método proxy para onChange.

Eche un vistazo a: https://studio.wavemaker.com/

Saludos, Vinay

¿Podrías publicar un ejemplo de este proxy y cómo se usa? Podría ayudar a depurar esto.

Vea el ejemplo en: http://plnkr.co/edit/Xe6ErQrg7WL6aAIoM9Gd?p=preview

¿Se solucionará pronto? Es taaaan confuso.

Después de una mayor consideración, debo decir que este es el comportamiento esperado. En el ejemplo de plnkr, el valor de ngModel es una cadena de dos enlaces entre el controlador y el alcance de la directiva. Ahora, cuando cambie el valor en la directiva, ngModel actualizará primero el alcance _isolate_ y activará ngChange en el mismo resumen. Dado que el enlace bidireccional aún no ha detectado un cambio en el alcance de la directiva, ngChange en el alcance principal obtiene el valor "antiguo" de x . Ahora, el observador de enlace bidireccional necesita al menos dos ciclos de resumen para estabilizar el valor, por lo que el alcance del controlador solo se actualiza después de que se haya llamado ngChange.
Estoy de acuerdo en que esto es confuso, pero así es como funciona. Puede solucionar esto vinculando un objeto a la directiva que contiene el valor que vincula a ngModel. De esa manera, el valor se establece por referencia tanto en el ámbito aislado como en el del controlador al mismo tiempo y está disponible cuando se ejecuta ngChange: http://plnkr.co/edit/fs7S6yX1a5aeo1Ese522?p=preview

Narretz, estoy totalmente en desacuerdo. Existe un contrato con el desarrollador que consume el código en el que el enlace bidireccional tiene prioridad. Cuando se realiza un cambio en cualquier parte de la cadena de enlace, se debe actualizar toda la cadena antes de continuar. Entonces, incluso si otra directiva hereda de esta directiva, y algo más abajo se une a un enlace de un enlace ... si ese modelo se actualiza, el modelo de alcance del controlador original en la parte inferior de la pila debe actualizarse en el mismo ciclo de resumen antes continuando con otras funciones. Es lo que se espera del consumidor.

Ligeramente relacionado y también confuso. Cuando se usa ngChange para activar la validación en otro campo que comparte un ngModel , el cambio se activa antes de que se actualice $modelValue . Haciendo la validación complicada.

Usando $timeout como solución. Todavía confundido por qué es necesario.

Ejemplo:
http://codepen.io/jakobadam/pen/qmBdrJ?editors=1010

saludos, Jakob

¿Hay planes para volver a examinar este tema? ¿Quizás reabrir?

Me encontré con este problema y leí los comentarios, mientras que la forma en que funciona actualmente debido al alcance aislado tiene sentido; el resultado que proviene de esperar un modelo actualizado cuando se activa la llamada de cambio y obtener el modelo una iteración anterior definitivamente no es el comportamiento que espera como desarrollador.

Me adhiero a la pregunta, ¿se volverá a revisar esto?

No lo creo. El comportamiento actual es el esperado y aunque no es deseable en algunos casos, hay al menos tantos casos en los que lo es. Cambiarlo ahora sería (a) un cambio rotundo y (b) haría que muchos casos de uso no fueran compatibles (por ejemplo, donde desea que ngChange modifique el valor _antes_ de que actualice el padre). Es uno de esos casos en los que no se puede hacer feliz a todo el mundo, así que tenemos que ceñirnos a la versión que:

• Tiene sentido.
• No rompe a los usuarios existentes.
• Admite casos de uso más específicos / avanzados, incluso a costa de un pequeño código adicional (ver más abajo).

La implementación actual de ngChange está estrechamente ligada al concepto de ngModel . Las vinculaciones directivas son un concepto totalmente independiente. Los dos pueden trabajar juntos muy bien, pero no deberían afectar la implementación / funcionamiento interno del otro.

#

Como ya se mencionó, si su devolución de llamada específica necesita acceso al valor actualizado, existen algunas opciones:

1. Pase el valor actualizado como argumento a la devolución de llamada.

2. Si necesita que se ejecute de forma asincrónica (es decir, después de que finalice el resumen y se hayan propagado todos los enlaces), siempre puede usar $timeout dentro de la devolución de llamada.

3. Si desea una versión "asíncrona" de ngChange , también es trivial implementarla como una directiva personalizada. (También puede sobrescribir la directiva incorporada, pero definitivamente no lo recomendaría). Por ejemplo:

.directive('myAsyncChange', function($timeout) {
  return {
    restrict: 'A',
    require: 'ngModel',
    link: function(scope, element, attr, ctrl) {
      ctrl.$viewChangeListeners.push(function() {
        $timeout(function() {
          scope.$eval(attr.myAsyncChange);
        });
      });
    }
  };
});

<input ng-model="foo" my-async-change="onChange()" />