AngularJS

Una single-page web application (en adelante SPA), es una aplicación web que se ejecuta completamente en una única página web, con el objetivo de proporcionar una experiencia más fluida y similar a la que nos encontraríamos en una aplicación de escritorio

En una aplicación SPA, todos los datos necesarios, como el HTML, CSS o JavaScript, se cargan y añaden en la página cuando es necesario, normalmente respondiendo a acciones del usuario. En ningún momento del proceso veremos una recarga total de la página. Para esto, como os imaginaréis a lo largo del proceso de ejecución de una aplicación SPA existe una comunicación con el servidor en segundo plano.

Según Martin Fowler[1], este patrón consiste en: Un mecanismo que garantiza que cualquier cambio realizado sobre los datos en un control de la interfaz, se traslada inmediatamente al estado de la sesión (y viceversa).

En una aplicaciónAngularJS el two-way data binding consiste en la sincronización automática entre los componentes del modelo y de la vista. La vista es una proyección del modelo en todo momento. Cuando realizamos un cambio sobre el modelo éste se refleja inmediatamente sobre la vista. image::img/ses01/02.png[{large-size}]

En AngularJS, este mecanismo funciona de la siguiente manera: una plantilla (que es código HTML) se compila en el navegador. Esta compilación hace que cualquier cambio en el modelo se refleje inmediatamente en la vista. También hará que todo cambio que realicemos en la vista se propage al modelo. El modelo es la single-source-of-truth del estado de la aplicación, lo que simplifica mucho las cosas, al no tener que gestionar más que el modelo, y pensar el la vista como una proyección de éste.

Dado que la vista es una proyección del modelo, el controlador queda totalmente separado de la vista y no es consciente de ella. De esta manera, realizar tests sobre un controlador es mucho más sencillo, ya que no depende de la vista ni de ningún elemento del DOM.

Imaginémonos que queremos implementar esta funcionalidad en JavaScript plano, o con jQuery. Tendríamos que hacer un número enorme de consultas al DOM para mantener esta funcionalidad, y hacer que se ejecute periódicamente para que los datos siempre se encuentren actualizados. Sin embargo, AngularJS ya realiza este trabajo por nosotros, y el data binding se realiza de manera transparente.

Así, para una pantalla que muestre el nombre de usuario, sería tan sencillo como declarar una variable con el nombre de usuario en nuestro código JavaScript:

En nuestra vista, utilizaremos la notación {{ }}, que nos pemite ligar expresiones a elementos:

Esto es lo que piensa Igor Minar, lead de AngularJS, cuando se entra en cuestiones sobre qué patrón sigue el framework.

A efectos prácticos, y como se dice en la cita, el patrón Model View ViewModel (MVVM) es una aproximación bastante cercana para describir de manera general el comportamiento de AngularJS.

El patrón MVVM funciona muy bien en aplicaciones con interfaces de usuario ricas, ya que la Vista se vincula al ViewModel y, cuando el estado del ViewModel cambia, la Vista se actualiza automáticamente gracias, precisamente, al two-way-databinding. En AngularJS, una Vista es simplemente código HTML compilado con elementos propios del framework. Una vez finaliza el ciclo de compilación, la Vista se vincula al objeto $scope, que es el ViewModel. Ya veremos en profundidad el objeto $scope, pero adelantamos que es un objeto JavaScript que captura ciertos eventos para permitir el data binding. También, podemos exponer funciones al ViewModel para poder ejecutar funciones.

image::img/ses01/003_mvvm.png

Ya veremos esto más adelante, y veremos lo sencillo que es trabajar con este patrón, que crea una separación muy clara entre la Vista y la lógica que la conduce. Uno de los "efectos secundarios" del patrón ViewModel, es que permite que el código sea muy testable.

Otra de las grandes características de AngularJS es el uso de HTML para la creación de plantillas. Éstas pueden ser útiles cuando queremos predefinir un layout con secciones dinámicas está conectado con una estructura de datos. Por ejemplo, para repetir un mismo elemento DOM en una página, como una lista o una tabla. Podríamos definir cómo queremos que se vea una fila, y después asociarle una estructura de datos, como un array de JavaScript. Esta plantilla se repetiría tantas veces como ítems encontremos en el array, asociando el ítem al contenido.

Hay muchas librerías de templating, y muy buenas. Pero para la mayoría de ellas se requiere aprender una nueva sintaxis. Esta complejidad adicional puede ralentizar al desarrollador. Además, muchas suelen pasar por un preprocesador.

El navegador evalúa las plantillas de AngularJS como el resto de HTML de la página. Hay cierta funcionalidad de AngularJS que gestiona cómo se representan los datos, que veremos cómo funciona en las próximas sesiones.

Como hemos comoentado, AngularJS es un framework para construir aplicaciones SPA. Sin embargo, es posible que nuestros usuarios no se den cuenta de este detalle. En muchas aplicaciones SPA modernas, está prohibido usar el back button ya que no se tiene en cuenta a la hora de programar. Sin embargo, AngularJS hace uso de la API de history de HTML5. ¿Que tu navegador no implementa esa API? Es igual, AngularJS seguirá gestionando bien el histórico gracias al control de cambios en el hashbang.

Para un usuario, esto significa que se pueden guardar y compartir cualquier estado de la apliación, cosa muy importante hoy en día debido al social media. También nos permite a los desarrolladores cambiar el estado de la aplicación de la manera más sencilla posible: mediante el uso de hipervínculos.

La inyección de dependencias (DI por sus siglas en inglés) describe una técnica que hemos estado usando toda la vida. Si alguna vez has usado una función que acepta un parámetro, ya has hecho uso de la inyección de dependencias. Inyectas algo de lo que depende tu función para realizar su trabajo. Nada más y nada menos.

image::img/ses01/004_di.png

Al modularizar tu código con elementos inyectables, éste es más fácil de testear, ya que en cualquier momento puedes reemplazar uno de los elementos por otro, siempre y cuando implemente la misma interfaz.

Veamos un sencillo caso de inyección de dependencias. El siguiente código no hace uso de ellas:

Con un código tan pequeño y tan simple, ya se plantean dos problemas:

Si usáramos DI, nuestro código tendría un aspecto similar al siguiente:

Este cambio tiene varias ventajas: por una parte, ya no dependemos del orden, y nuestro código no tiene que seguir una secuencia. estp implica que, podemos extraer cualquiera de los bloques a otro fichero, lo que en aplicaciones grandes será más que conveniente. Además, en cualquier momento podemos sobreescribir cualquiera de las funciones, cosa muy importante para realizar tests.

Las directivas son la parte más interesante de AngularJS, ya que nos permiten extender HTML para que realice todo lo que nosotros queramos.

Podemos crear elementos del DOM personalizados, atributos o clases que incorporan cierta funcionalidad definida en JavaScript. Aunque HTML es excelente para definir un layout, para el resto se queda corto. Las directivas nos proporcionan un mecanismo para unir la naturaleza declarativa de HTML con la naturaleza funcional de JavaScript en un mismo elemento. Así, cuando aprendamos a utilizar directivas, en lugar de pintar un modal de bootstrap de esta manera:

Lo haremos de esta otra:

Para los curiosos, podéis ir jugando con el código de este modal en http://jsfiddle.net/alexsuch/RLQhh/.

Ahora que tenemos nuestra lógica de navegación implementada, vamos a ver de qué manera podemos comunicarnos con el controlador. Para ello, en el listado de profesores, vamos a introducir la posibilidad de crear uno nuevo.

Fijémonos en el botón, que incorpora una nueva directiva, llamada ng-click. Ésta responde al evento onClick, realizando una llamada a la función addTeacher().

Como hemos dicho antes, la vista no sabe nada del controlador. Pero disponemos del objeto $scope, que permite exponer elementos del controlador en la vista. Lo hemos hecho con una colección (el array de profesores), y también podemos exponer una función:

Vemos que no se ha pasado ningún dato como parámetro, ya que al pasarlo como ng-model en nuestros inputs, ya lo podemos obtener a través del $scope.

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. <<<

Digamos que queremos un servicio muy sencillo, llamado clientId, que nos devuelve un String que representa el identificador de usuario que usamos para alguna API remota. Lo podríamos definir de esta manera

Hemos creado un módulo de AngularJS llamado myApp. Posteriormente, hemoss dicho que este módulo contiene la receta para construir el servicio clientId, que en este caso únicamente devuelve una cadena.

Si quisiéramos mostrarlo vía two-way data binding lo haríamos de la siguiente manera:

En este ejemplo, hemos usado la receta Value para dársela a DemoCtrl cuando invoca al servicio clientId.

Un Value es fácil de escribir, pero se echan de menos unos elementos importantes que necesitamos a menudo a la hora de escribir servicios. Así, pasaremos a conocer un elemento más complejo, llamado factory. Una factory nos permite:

Una factory construye un nuevo servicio mediante una función con cero o más argumentos. Estos argumentos son dependencias con otros servicios, que se inyectarán en tiempo de creación.

Una factory no es más que una versión más potente de un Value, de manera que podemos reescribir el servicio clientId de la siguiente manera:

Pero dado que el token no es más que un a cadena, quizá crear un Value sería más apropiado en este caso, y el código sería además más sencillo de interpretar.

Digamos que, por ejemplo, queremos crear un servicio encargado de calcular un token para autenticarse contra una API remota. Este token se llamará apiToken y se calculará en función del valor de clientId, y de una clave secreta guardada en el almacenamiento local del navegador:

En el código anterior, vemos cómo se define el servicio apiToken con la receta de una factory que depende del servicio clientId. Entonces crea un token de autenticación a través de una encriptación hiperpotente indescifrable por la NSA [3].

De igual manera que un Value una factory puede crear un servicio de cualquier tipo, ya sea una primitiva, un objeto, una función o una instancia de un tipo de dato propio.

Los desarrolladores JavaScript usan tipos de datos custom para escribir código OO. Veamos cómo podríamos lanzar un Unicornio [4] al espacio mediante un servicio unicornLauncher, que es una instancia del siguiente objeto:

Ya podemos lanzar unicornios al espacio, pero démonos cuenta que nuestro lanzador requiere un apiToken. Lo bueno es que ya habíamos creado una factory que resolvía este problema.

Éste es, precisamente, el caso de uso más adecuado para un Service.

La receta de un Service produce un servicio, de igual manera que habíamos visto con Value y factory, pero lo hace invocando un constructor mediante el operador new. El constructor puede recibir cero o más argumentos, que representan dependencias que necesita la instancia de este tipo.

Además, un Service sigue un patrón de diseño llamado constructor injection. De manera que es el propio AngularJS quien se encarga de instanciar un nuevo objeto de la clase dada. Como nuestro UnicornLauncher tiene un constructor, podemos reemplazar la factory por un Service, de la siguiente manera:

Como se ha dicho anteriormente, el Provider es la base sobre la que se crean el resto de servicios que hemos visto en los apartados anteriores. Precisamente porque es la base sobre la que se asientan el resto, no será difícil comprender que es la que nos ofrece mayores posibilidades. Pero en la mayoría de los casos todo lo que ofrece es excesivo, y será recomendable hacer uso de los otros servicios.

La receta de un Provider se define como un tipo propio que implementa un método $get. Este método es una función factoría [5], como el que se usa en una factory. De hecho, si definimos una factory, lo que se hace es crear un Provider vacío cuyo método $get apunta directamente a nuestra función.

Deberíamos usar un Provider cuando queremos introducir cierta configuración que esté disponible a para toda la aplicación. Para asegurar esto, esto debe hacerse antes de que se ejecute la aplicación, en una fase llamada fase de configuración. De esta manera, podemos crear servicios reutilizables cuyo comportamiento podría cambiar ligeramente entre aplicaciones.

Por ejemplo, nuestro lanzador de unicornios es tan potente y útil que lo van a usar muchas de las aplicaciones del parque de aplicaciones de nuestra empresa. Por defecto, el lanzador de unicornios los proyecta al espacio sin ningún tipo de protección ni escudo. Pero en algunos planetas, la atmósfera es tan pesada que debemos proteger a nuestros unicornios con papel de plata para evitar que se incineren al atravesar la atmósfera y así evitar su extinción. Estaría muy bien que pudiéramos configurar esto nuestro lanzador, y usarlo en la app que haga falta. Lo haríamos configurable de la siguiente manera:

Para activar el traje espacial de papel de plata, necesitamos crear una función config en la API de nuestro módulo, e inyectar en ella el unicornLauncherProvider:

Observemos que el Provider ha sido inyectado en la función de configuración. Esta inyección la hace in provider injector, que es distinto del inyector de instancias habitual que usaremos en el resto de nuestra aplicación. Este inyector únicamente trabaja con providers, ya que el resto de objetos no se crean en la fase de configuración.

Durante la inicialización de la aplicación, antes de que AngularJS haya creado ningún servicio, configura e instancia los providers. A esto lo llamamos la fase de configuración del ciclo de vida de la aplicación. Durante esta fase, como hemos dicho, los servicios no son accesibles porque aún no se han creado.

Una vez se ha finalizado la fase de configuración, ya no se puede interactuar con un Provider y empieza el proceso de crear servicios. A esta parte del ciclo de vida de la aplicación se le conoce como fase de ejecución.

Hemos visto cómo AngularJS divide el ciclo de vida de una aplicación en las fases de configuración y ejecución, y cómo se puede dotar de configuración a la aplicación a través de la función config. Dado que la función config se ejecuta en una fase en la que no tenemos servicios disponibles, no se tiene acceso ni siquiera a objetos sencillos creados con la utilidad Value.

Sin embargo, podemos tener valores tan simples como un prefijo de una url, que no necesiten dependencias o configuración, y que sean útiles en las fases de configuración y ejecución. Para esto sirve la utilidad constant.

Supongamos que nuestro servicio unicornLauncher puede estampar, en un unicornio, el nombre del planeta contra el que está siendo lanzado en la fase de configuración. El nombre del planeta es específico para cada aplicación, y también lo usan muchos controladores en tiempo de ejecución. Podemos definir entonces el nombre del planeta como una constante:

Ahora, podemos configurar nuestro unicornLauncherProvider de la siguiente manera:

Y dado que una constant hace que el valor también esté disponible en la fase de ejecución, podemos usarla también en nuestros controladores:

En nuestro módulo, debemos crear una factoría. La llamaremos productsFactory y expondrá un único método, llamado getProducts(), que devolverá el listado de productos que teníamos en el controlador. Inyectaremos la factoría en el controlador, y ahora el listado de productos será $scope.products = productsFactory.getProducts().

Para usar un filtro en una vista, podemos aplicar una expresión con la siguiente sintaxis:

Los filtros, además, pueden encadenarse. En el siguiente ejemplo, la salida del primer filtro se pasa como entrada del segundo.

Para usar un filtro en un controlador/servicio/directiva, debemos inyectar una dependencia con <nombreDelFiltro>Filter. Por ejemplo, para usar el filtro number que hemos visto en el ejemplo anterior (que formatea un número con los decimales indicados en el segundo parámetro), inyectaríamos numberFilter.

Otra manera consiste en inyectar el servicio $filter en nuestro código javascript. Con él, podemos llamar a todos los filtros de la siguiente manera:

El filtro filter selecciona un subset de ítems dentro de un array, devolviéndolo en un nuevo array

En una plantilla HTML lo usaremos de la forma:

En nuestro código javascript lo usaremos de la siguiente forma:

El parámetro array se corresponde con el array a filtrar. Por su parte, expression puede ser una cadena (búsqueda en todos los objetos), o bien un objeto (que servirá de "ejemplo" para hacer las búsquedas en el array). El último parámetro es opcional nos permite implementar una función de comparación customizada.

Ejemplo:

El filtro currency nos permite expresar un número en formato moneda. En una plantilla HTML lo usaremos de la forma:

En nuestro código javascript lo usaremos de la siguiente forma:

Tanto currency como fractionSize son opcionales. Si no ponemos nada, se expresará en dólares con el formato de separación de miles y decimales estadounidense. Para expresarlo a una región en concreto, lo mejor es instalar el módulo ngLocale que corresponda, en nuestro caso sería angular-locale_es-es.js. Según la versión de AngularJS que estemos utilizando, tendremos que añadirlo a nuestro módulo principal.

Ejemplo:

El filtro date nos permite formatear una fecha de la manera deseada. En una plantilla HTML lo usaremos de la forma:

En nuestro código javascript lo usaremos de la siguiente forma:

El parámetro date puede ser de varios tipos, aunque lo más habitual es que sea un objeto Date o una fecha en milisegundos. Tanto format como timezone son opcionales. En la referencia de este filtro en la web de AngularJS podemos ver todas las formas que acepta.

El filtro date también se ve afectado por el módulo ngLocale. Ejemplo:

El filtro json recibe un objeto como entrada, y devuelve una cadena representando dicho objeto en formato JSON. En nuestro código HTML se usa de la siguiente forma:

En nuestro código javascript lo usaremos de la siguiente forma:

El parámetro spacing es opcional, e indica el número de espacios que se utilizará en la indetación (el valor por defecto es 2). En el este enlace podemos ver el siguiente ejemplo funcionando:

El filtro limitTo recibe como entrada un array, del que tomará un número de elementos igual al parámetro recibido (limit). Estos elementos se tomaran del principio si el número es positivo, y del final si es negativo. En nuestro código HTML se usa de la siguiente forma:

En nuestro código javascript lo usaremos de la siguiente forma:

Ejemplo:

El filtro lowercase convierte una cadena a minúsculas. En nuestro código HTML se usa de la siguiente forma:

En nuestro código javascript lo usaremos de la siguiente forma:

Ejemplo:

El filtro uppercase convierte una cadena a mayúsculas. En nuestro código HTML se usa de la siguiente forma:

En nuestro código javascript lo usaremos de la siguiente forma:

Ejemplo:

El filtro number formatea un número en el locale que hayamos importado, y con el número de decimales indicado en su segundo parámetro, que es opcional.

En nuestro código javascript lo usaremos de la siguiente forma:

Ejemplo:

El filtro orderBy nos permite ordenar un array por una propiedad, en sentido normal o inverso. En nuestro código HTML se usa de la siguiente forma:

En nuestro código javascript lo usaremos de la siguiente forma:

Veamos un ejemplo de cómo funciona, y lo sencillo que es el uso de expression:

La documentación de AngularJs dice que expression puede ser una función que podemos getionar, por ejemplo, en nuestro controlador. Ejemplo:

Modifica el ejemplo del carrito de la compra para que los importes se formateen en euros y formato español de decimales. Revisa la documentación del filtro currency, porque tendremos que asegurarnos que siempre se muestren dos decimales, haya más o menos en el importe determinado para un prodcto en el servicio.

Vamos a crear un filtro propio que nos devuelva el nombre del producto. Este filtro se llamará productFullName.

Recibirá como parámetro un objeto de tipo producto, con lo que en la vista lo pasaremos de la siguiente manera:

Este filtro mostrará, concatenados, la marca y el nombre del producto. La marca deberá mostrarse en mayúsculas, y no deberemos usar la función toUpperCase() de JavaScript, sino inyectar el filtro upperCaseFilter en nuestro filtro y hacer uso de él.

Vamos a crear un filtro personalizado para la puntuación de los productos. Mostrará la puntuación en forma de estrellas. Se mostrarán tantas estrellas rellenas como puntuación tenga el producto, y luego se mostrarán estrellas vacías hasta llegar a un total de cinco. Por ejemplo, una puntuación de 3 mostrará ★★★☆☆.

Para ello, vamos a crear un filtro de propósito general. Éste, por tanto, no recibirá un objeto como parámetro sino un valor. También, recibirá un parámetro adicional, que será el máximo de puntuación del producto. En este caso la puntuación máxima son cinco estrellas, pero de esta manera e filtro también nos valdrá para cuando puntuemos sobre diez.

Modificaremos nuestra plantilla para mostrar la puntuación debajo del importe:

En el fragmento de código anterior, hemos visto dos bloques que hacen uso de la directiva ngInclude. Ésta se encarga de obtener un fragmento de HTML, compilarlo e introducirlo en nuestra aplicación.

Es muy útil para insertar elementos parciales que se van a repetir a lo largo de nuestra aplicación. Por ejemplo, en el bloque anterior se ha utilizado para añadir la cabecera y el pie de la aplicación. Son dos elementos que van a estar siempre ahí, y no queremos "ensuciar" nuestro fichero index.html con su código.

Aquí tenemos un enlace de una aplicación en ese estado.

Fijáos que la directiva recibe como parámetro una expresión, por eso su valor está entre comillas simples.

Para navegar de una ruta a otra desde una vista, lo haremos de manera exactamente igual a como lo haríamos en HTML: con la etiqueta <a>. No obstante, los destinos irán todos precedidos por el hashbang. Por ejemplo:

Para referenciar una ruta variable, podemos hacerlo de igual manera, haciendo uso de las variables de AngularJS:

Sin embargo, cuando utilizamos código dinámico (variables, funciones, etc.) en un enlace, la manera más correcta de hacerlo es utilizando la directiva ngHref.

En algunas ocasiones al generar el enlace dinámico anterior, podría darse el caso de que el usuario hace clic antes de que AngularJS haya tenido la oportunidad de establecer el valor dinámico. Al usar la directiva ngHref, AngularJS no establece el valor del atributo href hasta que ha podido interpretar el valor completo de la cadena. Así, lo que hace es traducir esto:

a esto otro:

en cuanto tiene la mínima oportunidad.

En no pocas ocasiones querremos que la redirección se haga en función de que cierta lógica de negocio se haya aplicado correctamente o no. Esto implica que dicha redirección tenga que hacerse desde un controlador u otro servicio. Para hacerlo desde aquí, recurriremos al servicio $location.

El servicio $location+ [11] parsea la URL de la barra de direcciones del navegador (según los valores de +window.location), y hace que la URL esté accesible para nuestra aplicación. Todo cambio que se haga en la URL se verá reflejado en el servicio $location y viceversa.

El servicio $location:

Estos métodos actúan a la vez como getters y setters, en función de si tienen o no parámetros. Así hemos podido ver cómo en el controlador NewOrderCtrl, redirigíamos a la página principal una vez insertado un pedido mediante la orden: