AngularJS

Cuando iniciamos una aplicación con AngularJS, se genera un scope a nivel de aplicación, llamado $rootScope. Desde ese momento, todo nuevo scope será hijo del $rootScope.

Podemos instanciar un nuevo $scope en cualquier momento a través del método $new(). Cuando lo instanciamos, un $scope hereda las propiedades de su padre, como vemos en este ejemplo:

Como hemos visto, podemos instanciar un nuevo scope en cualquier momento, lo normal es que AngularJS lo haga por nosotros cuando lo necesitemos. Por ejemplo, la directiva ngController instancia un nuevo scope, que será el que inyecte en el controlador. En este caso, el scope será hijo del $rootScope.

A las directivas que crean nuevos scopes se las conoce como scope creating directives, y como hemos dicho será el propio AngularJS el encargado de crear los scopes por nosotros cuando se encuentre con una de estas directivas en el árbol del DOM.

Ahora que sabemos que algunas directivas crean nuevos scopes hijos, quizá nos preguntemos por qué tanta complejidad. Para entenderlo, echemos un ojo a este ejemplo que utiliza la directiva ng-repeat:

El controlador sería:

Nuestra plantilla tendría la siguiente forma:

La directiva ng-repeat nos permite iterar sobre una colección de, en este caso, personas. Mientras itera, irá creando nuevos elementos en el DOM. El problema es que si utilizáramos el mismo $scope, estaríamos sobreescribiendo el valor de la variable persona. AngularJS soluciona este problema creando un nuevo $scope para cada elemento de la colección. Como se ha comentado, los scopes generan una jerarquía en forma de árbol, similar a la de los elementos del DOM. La extensión de AngularJS para Chrome nos permite verla:

Podemos ver en el pantallazo que cada scope (delimitado por un recuadro rojo) tiene su propio conjunto de valores del modelo. Así, cada item tiene su propio namespace, donde cada <li> posee un scope propio donde se puede definir la variable person.

Otra característica interesante de los objetos scope es que toda propiedad que definamos en un scope será visible para sus descendientes. Es muy interesante porque hace que no sea necesario redefinir elementos a medida que creamos scopes hijos.

Siguiendo con el ejemplo anterior, podemos calcular, en el scope del controlador padre, el número total de horas en base al conjunto de gente:

Como habíamos comentado, este total de horas se propagará a los ámbitos hijos, que podrán hacer uso de él para, por ejemplo, determinar el porcentaje del total que supondrá cada asignatura:

La herencia de scopes sigue el mismo patrón que la herencia prototípica de JavaScript: si no encontramos una propiedad en el objeto, subimos por el árbol de la jerarquía hasta dar con ella.

La herencia resulta muy sencilla de usar cuando estamos leyendo, pero sin embargo cuando estamos escribiendo puede darnos algún problema. Supongamos el siguiente bloque de código:

Si manipulamos el segundo input, todos los elementos se modificarán a la vez. Pero, ¿qué sucede si modificamos el primero, y luego el segundo nuevamente? Parece como que el primero queda desconectado del resto. De hecho, se crea una nueva variable en el scope hijo que hace que esto funcione de esta manera. Podéis hacer la prueba usando el inspector de AngularJS para Chrome.

Esto se debe a la herencia prototípica (prototipal inheritance a partir de ahora) de JavaScript, y todas las reglas que se aplican a ésta, se aplican a los scopes, que al fin y al cabo son objetos JavaScript. El scope no es el modelo, sino que referencia al modelo. Por tanto, en el momento que modificamos el primer input, que tiene un scope propio, estamos referenciando a un nuevo modelo.

Esto es fácil de solucionar, haciendo uso de objetos. Podemos redeclarar el objeto myModel de la siguiente manera:

Y usarlo así en nuestra vista:

De esta manera, estaremos referenciando siempre al mismo objeto y no tendremos elementos desconectados sin querer.

Existe otra manera, que es hacer uso del elemento parent. Éste hace referencia al ámbito padre, y lo podríamos llamar de la siguiente manera en el switch:

Sin embargo, esto resolvería nuestros problemas sólo si el dato estuviera en el ámbito padre, no si el padre también lo hubiera heredado. Además, no podemos estar seguros al 100% que parent va a ser el ámbito superior, ya que puede que estemos empleando alguna directiva que haya creado un scope adicional.

Como hemos comentado, en nuestra aplicación se generará un árbol de objetos scope similar a la estructura del DOM. En la raíz de este árbol se encuentra el objeto $rootScope

Podemos usar esta jerarquía para transmitir eventos dentro del árbol, tanto en dirección ascendente con el método scope.$emit como descendente con scope.$broadcast.

La captura de estos eventos se realiza con el método scope.$on.

La función scope.$emit(name, args); envía un evento hacia arriba en la jearquía, notificando a todos los listeners. El ciclo de vida del evento comienza en aquel scope que ha llamado a $emit. Este evento irá hacia arriba hasta llegar al $rootScope, y todos los que hayan dado de alta un listener y estén en el camino del evento serán notificados. Los suscritos a un evento pueden cancelarlo.

Por su parte, la función scope.$broadcast(name, args); envía un evento hacia abajo en la jearquía, notificando todos los listeners herederos.

Ambos métodos tienen los mismos argumentos:

Para suscribirnos a un evento, lo hacemos con scope.$on(eventName, listener) . Los parámetros son:

El objeto event que se le pasa al listener tiene los siguientes atributos:

El flujo normal de un browser cuando se recibe un evento es que éste termine llamando a una función JavaScript de callback. Una vez ésta ha finalizado, el browser renderiza el DOM de nuevo y espera a recibir más eventos.

Cuando se hace esta llamada JavaScript al navegador, el código se ejecuta fuera del contexto de ejecución de AngularJS, lo que significa que AngularJS no tiene ni idea de que se haya modificado el modelo. Para poder procesar estas modificaciones en el modelo, hay que hacer que todo lo que se ha hecho fuera del contexto de ejecución de AngularJS entre dentro de él a través del método $apply. Sólo las modificaciones del modelo que hagamos dentro de un método $apply serán tenidas en cuenta por AngularJS. Por ejemplo, una directiva como ng-click que escucha eventos del DOM, debe evaluar la expresión dentro de un método $apply. Así lo podemos ver En su código fuente.

Tras evaluar la expresión el método $apply realiza un $digest. En esta fase, el scope examina todas las expresiones $watch y compara sus resultados con los valores previos de manera asíncrona. Esto significa que una asignación como $scope.username = 'admin' no lanzará inmediatamente el listener de $watch('username'). En lugar de eso, se retrasará hasta la fase de $digest, de manera que se unifican las actualizaciones del modelo, y se garantiza que se ejecute una función $watch a la vez. Si un $watch cambia el modelo, forzará un ciclo $digest adicional.

Esto podemos resumirlo en las cinco fases por las que pasa una aplicación en AngularJS:

Podemos instanciar una clase en JavaScript de la siguiente manera:

var myInstance = new myClass(); ---

De esta manera podemos utilizar la instancia myInstance para acceder a métodos y propiedades de la clase. Ésto mismo es lo que nos permite la sintaxis Controller As:

Cuando instanciamos un controlador en el DOM, tenemos que hacerlo contra una variable:

Cuando tenemos controladores anidados es cuando vemos las ventajas de la sintaxis controller as. Muchas veces tenemos que acceder a la propiedad $parent del scope en que nos encontramos para obtener lo que queremos:

Aquí podemos hacernos un lío y no saber muy bien a qué variable title estamos accediendo. Sin embargo, con la sintaxis controller as estamos definiendo un namespace que nos clarifica perfectamente a qué estamos accediendo:

Con esta mecánica también podemos acceder a los scopes padres de una manera sencilla:

E incluso hacer cosas más mágicas:

No hacky $parent calls. If a Controller’s position in the DOM/stack were to change, the position in sequential $parent.$parent.$parent.$parent may change! Accessing the scope lexically makes perfect sense.

$watchers/$scope methods The first time I used the Controller as syntax I was like “yeah, awesome!”, but then to use scope watchers or methods (such as $watch, $broadcast, $on etc.) we need to dependency inject $scope. Gargh, this is what we tried so hard to get away from. But then I realised this was awesome.

The way the Controller as syntax works, is by binding the Controller to the current $scope rather than it being all one $scope-like class-like Object. For me, the key is the separation between the class and special Angular features.

This means I can have my pretty class-like Controller:

app.controller('MainCtrl', function () { this.title = 'Some title'; }); When I need something above and beyond generic bindings, I introduce the magnificent $scope dependency to do something special, rather than ordinary.

Those special things include all the $scope methods, let’s look at an example:

app.controller('MainCtrl', function ($scope) { this.title = 'Some title'; $scope.$on('someEventFiredFromElsewhere', function (event, data) { // do something! }); }); Ironing a quirk Interestingly enough, whilst writing this I wanted to provide a $scope.$watch() example. Doing this usually is very simple, but using the Controller as syntax doesn’t work quite as expected:

app.controller('MainCtrl', function ($scope) { this.title = 'Some title'; // doesn’t work! $scope.$watch('title', function (newVal, oldVal) {}); // doesn’t work! $scope.$watch('this.title', function (newVal, oldVal) {}); }); Uh oh! So what do we do? Interestingly enough I was reading the other day, and you can actually pass in a function as the first argument of a $watch():

app.controller('MainCtrl', function ($scope) { this.title = 'Some title'; // hmmm, a function $scope.$watch(function () {}, function (newVal, oldVal) {}); }); Which means we can return our this.title reference:

app.controller('MainCtrl', function ($scope) { this.title = 'Some title'; // nearly there…​ $scope.$watch(function () { return this.title; // this isn’t the this above!! }, function (newVal, oldVal) {}); }); Let’s change some execution context using angular.bind():

app.controller('MainCtrl', function ($scope) { this.title = 'Some title'; // boom $scope.$watch(angular.bind(this, function () { return this.title; // this IS the this above!! }), function (newVal, oldVal) { // now we will pickup changes to newVal and oldVal }); });

Este ejercicio lo realizaremos en una carpeta llamada calculator.

Completa el siguiente código para implementar una calculadora que haga sumas, restas, multiplicaciones y divisiones.

Este ejercicio lo realizaremos en una carpeta llamada shoppingcart.

Vamos a hacer uso de la función $watch que nos ofrece el scope para implementar un sencillo carro de la compra.

Disponemos de una plantilla ya hecha, que muestra un listado de productos (generados aleatoriamente con JSON Generator). También, disponemos de un controlador donde tenemos el listado de productos, una serie de variables y una función addToCart vacía.

Tendremos que implementar la función addToCart, para que añada ítems al carro. Además, implementaremos un watcher que observará cambios en el tamaño de dicho array. Cuando éstos se produzcan, actualizaremos la variable $scope.totalItems al número de ítems del carro. También, actualizaremos el valor de la variable $scope.total, con el importe total de los productos. Se recomienda hacer uso de la función Array.prototype.reduce para calcular este total.

La plantilla de nuestro índice será:

Por su parte, la plantilla de nuestro controlador será:

Este ejercicio lo realizaremos en una carpeta llamada ping-pong.

En este ejercicio vamos a probar la propagación de eventos. Dispondremos de la siguiente plantilla HTML:

Y la siguiente plantilla JavaScript:

Si ahora pulsamos en cualquiera de los dos primeros botones, veremos que los contadores ping y pong adquieren los mismos valores.

Deberemos:

No se puede renombrar ninguno de los nombres de variable de la vista (todos deben llamarse ping y pong).

Tener en cuenta la herencia prototípica que hemos estado viendo.

Se ha introducido un poco de CSS para que se delimiten bien los tres scope que hay en la aplicación.

Si los bloques ng-init te molestan, puedes quitarlos

Realiza el ejercicio anterior del carrito de la compra aplicando la sintaxix de controller as. Seguiremos necesitando el objeto scope para nuestros watchers. Recordemos que podíamos pasar una expresión o una función a nuestro watcher

Como dentro de una función el ámbito del this varía, una manera sencilla de solventar esto es de la forma:

Hay maneras más elegantes de hacerlo, como mediante el uso de bind u otras técnicas de binding, pero la descrita es una forma comúnmente usada en infinidad de proyetos.