En este post explicaré como crear la estructura básica del diseño de una aplicación con Angular y Angular material design. Angular material design es una colección de componentes visuales optimizados para una mejor experiencia de usuario y creación de interfaces gráficas.
Utilizarlo nos ahorra mucho tiempo creando y diseñando nuestros propios componentes, por lo que es una buena opción para acelerar las creación de aplicaciones web.
Primero vamos a crear una nueva aplicación con **angular-cli:
$ ng new basic-angular-material
Luego ejecutamos nuestra aplicación con ng serve:
cd basic-angular-material && ng serve
Nuestra aplicación se debería de ver así:
Ahora instalamos el paquete de Angular material:
npm install --save @angular/material @angular/cdk
Si te das cuenta, ademas de instalar el paquete de @angular/material, también instalamos el paquete @angular/cdk, este ultimo en versiones anteriores formaba parte del paquete de @angular/material, pero es tan útil en la creación de componentes que ahora es independiente y al serlo permite que otros desarrolladores se beneficien para crear sus propios componentes al mero estilo de angular material.
Como muchos componentes de angular material realizan animaciones para una mejor experiencia de usuario, si queremos que nuestros componentes tengan animaciones debemos instalar el paquete @angular/animationse importar el modulo BrowserAnimationModuleen nuestra aplicación.
npm install --save @angular/animations
En el archivo src/app/app.module.tsimporta el modulo de animaciones, lineas 7 y 16, en el código de ejemplo:
Ahora debemos incluir un tema para nuestra app, es requerido para la correcta visualización de la mayoría de los componentes. Debemos incluir la siguiente linea de código en el archivo /src/styles.css.
Para que los componentes reaccionen bien a eventos de touch en pantallas, necesitamos de la librería HammerJS, varios componentes utilizan HammerJS así que lo podemos instalar con el siguiente comando:
npm install --save hammerjs
En el archivo /src/main.tsimportamos la librería en la linea 8.
Importamos los módulos de Angular Material que vayamos a utilizar. Vamos a modificar el archivo src/app/app.module.tspara que quede como el código de abajo. Otra opción es crear un modulo nuevo donde importemos los componentes de angular material que vayamos a utilizar. En este ejemplo importamos los componentes en la linea 9.
Con todo lo anterior listo, podemos empezar a utilizar los componentes, vamos a modificar el contenido por defecto del template del componente principal que nos genera la herramienta de linea de comandos de angular-cli.
Versión final:
Nuestra app debe verse así:
Y cuando damos click(o touch) en el menú:
Para que tu app se vea de esta manera, sin espacios en blanco a los lados y la barra lateral a toda la altura del navegador web, tu archivo src/styles.cssdebe ser así:
Demo de interfaz gráfica para creación de encuestas. Angular 5 y Angular material design 5:
Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, y luego describe el núcleo de la solución a ese problema, de tal manera que puedes utilizar esta solución millones de veces, sin nunca hacerlo de la misma forma dos veces.
Arquitecto Christopher Alexander
La definición del patrón de diseño no viene del desarrollo de software, sino de la arquitectura del habitat humano.
Tanto la arquitectura del hábitat humano como el desarrollo de software tienen muchas similitudes, esto es porque como seres humanos somos parte del mundo y de la naturaleza. Por lo tanto el desarrollo de software busca siempre representar el mundo real, de hecho la programación de cualquier aplicación siempre se usa para solucionar problemas reales de nuestro entorno.
Entonces podemos comprender que un patrón de diseño permite ofrecer una solución a problemas comunes en el diseño de software, describe la solución a problemas que se repiten muchas veces y que son muy similares entre ellos, en concreto, esta similitud permite diseñar una solución para un conjunto de problemas parecidos.
Los patrones de diseño actuales fueron popularizados por el libro Design patterns: elements of reusable object-oriented softwarede los autores conocidos como GoF(Gang of Four):
Erich Gamma
Richard Helm
Ralph Johnson
John Vlissides
En este libro se describen 23 patrones de diseño que desde 1995 hasta nuestros días siguen en uso con un gran impacto en el desarrollo de software. Esto no quiere decir que estos patrones no fueron utilizados mucho antes de la publicación del libro.
Este artículo será el primero de una serie, que nos permitirá entender como se pueden implementar muchos de estos patrones de diseño en el lenguaje de programación Javascript y no solo los descritos por GoF, también se explicara otros patrones de diseño útiles en Javascript.
El primer patrón de diseño es el Patron Singleton.
Patrón Singleton
Este patrón nos permite tener una solo instancia de un tipo de objeto, porque no es necesario crear varias instancias nuevas cuando una solo instancia puede encargarse del mismo trabajo en toda la aplicación. Al solo tener una instancia, centralizamos la información, funcionalidad y mejoramos el rendimiento disminuyendo el uso de memoria.
En Javascript es muy fácil utilizar este patrón, tan fácil como crear un objeto literal, por ejemplo supongamos que tenemos una configuración para el número de caracteres y palabras que se muestran en un sitio web optimizado para buscadores:
let configSEO ={name:'Pensemosweb',seo:{descripcion:{limiteCaracteres:155,limitePalabras:23},titulo:{limiteCaracteres:70,limitePalabras:9}}};
Un simple objeto de configuración es un singleton, pues en toda la app se va a hacer referencia al objeto configSEO y nunca se va a crear más nuevos objetos porque se puede extender esa configuración añadiendo más propiedades.
Ahora supongamos que necesitamos utilizar objeto donde existan funciones de configuración y métodos, además de una interfaz para obtener la instancia, tomando el mismo ejemplo de configSEO ahora vamos a utilizar funciones anidadas y closure (o cierres), esto ultimo permite a una función tener acceso a las funciones y variables definidas en el ámbito en que esta función también es definida.
La función anónima principal se invoca inmediatamente con la notacion (function() {}()) y recibe un parámetro el, el cual guarda la referencia al elemento del DOM con id resultado. Este parámetro se lo pasamos a la función inmediata a través de la variable global elem.
Debido a que definimos instancia dentro de la función principal, las funciones anidadas definidas más adelante tienen acceso a esa variable instancia que guardara nuestro singleton cuando invoquemos la función configSEO().
Además metodoPublico()and privada() tienen acceso a las variables instancia and el.
Si nos fijamos en la línea 48, elem.append(conf1 === conf2), comparamos igualdad de referencia, conf1and conf2son el mismo objeto, como singleton, solo trabajamos con una instancia.
También podemos hacer uso de otro patrón de diseño llamado factory, el cual veremos más a detalle en otro post, por el momento solo ten en cuenta que tendremos una función que fabricara singletons.
Podemos notar que con una sola función, podemos acceder a los singletons creados anteriormente y podemos agregar más si queremos. Este tipo de patrón factory de singletons es muy utilizado en frameworks como AngularJS. Aquí abajo un ejemplo del singleton configSEO y el factor y usando AngularJS.
Antes de empezar a describir los Hooks del ciclo de vida de un componente en angular quiero citar la definición de Hooking de wikipedia:
El término Hooking abarca una gama de técnicas utilizadas para alterar o aumentar el comportamiento de un sistema operativo, aplicaciones o de otros componentes de software interceptando llamadas de función o mensajes o eventos pasados entre componentes de software. El código que maneja tales llamadas de función, eventos o mensajes interceptados se le llama un Hook.
En angular tenemos estos hooks, que son funciones ejecutadas en puntos claves del ciclo de vida de un componente.
Tanto los componentes y las directivas pueden ejecutar estas funciones. Pero las directivas no ejecutan las funciones de color azul, las cuales son específicas de la vista y contenido de componentes.
Dado que normalmente se utiliza typescript en Angular para obtener el código javascript final. Vamos a implementar estos métodos utilizando la interfaz que le corresponde a cada uno. Todas estas interfaces están en el modulo @angular/core.
Por ejemplo, para implementar el método ngOnInit, debemos importar la interfaz OnInit:
import { Component, OnInit } from '@angular/core';
El lenguaje de javascript no tiene interfaces, estas interfaces las agrega typescript para obtener un Javascript fuertemente tipeado y basado en clases. Aunque las ultimas versiones de javascript utilizan una sintaxis de clases casi idéntica, por detrás realmente son funciones y herencia prototipal.
Todos los hooks del ciclo de vida de un componente en acción
Más abajo tenemos ejemplos de todos los hooks en acción y están basados en el código de la documentación oficial de Angular. Para ver mejor el código y el funcionamiento en tiempo real, siempre puedes presionar este botón:
Existe un componente de tipo ParentComponent y otro ChildComponent. He ParentComponent se encarga de crear el ChildComponent, de esta manera será más fácil poder ver en acción los hooks. También se encarga de bindear la propedad name y actualizarla para poder ver el hook ngOnChanges.
Como te darás cuenta viendo el archivo /app/all/child.component.ts, este componente implementa todas las interfaces de los hooks.
Si presionas el botón Crear ChildComponent, el mensaje #1 es en el constructor del componente, el constructor normalmente se utiliza para definir valores iniciales simples, nunca pongas mucha lógica en el constructor. Además podemos notar que la propiedad name en este punto, aun no esta definida.
Después tenemos el mensaje #2, este es del hook ngOnChanges, aquí es cuando ocurre el enlazado de las propiedades con la nueva instancia de nuestro ChildComponent, en este punto la propiedad name ahora si esta definida.
Luego tenemos la ejecución de ngOnInit, ngDoCheck, ngAfterContentInit, ngAfterContentChecked, ngAfterViewInit, ngAfterViewChecked en ese orden.
Ahora si presionas el botón Actualizar ChildComponent, se actualiza la propiedad name desde el ParentComponent, podemos ver como se ejecutan ngDoCheck, ngAfterContentChecked, ngAfterViewChecked, y otra vez ngOnChanges, ngDoCheck, ngAfterContentChecked y finalmente ngAfterViewChecked. Aquí podemos afirmar dos cosas:
ngDoCheck, ngAfterContentChecked, ngAfterViewChecked se invocan en ese orden al detectar un cambio.
También se ejecutan siempre tras un ngOnChanges pues se volvieron a ejecutar en ese mismo orden
Finalmente, si presionas el botón Destruir ChildComponent, los hooks ngDoCheck, ngAfterContentChecked, ngAfterViewChecked se vuelven a ejecutar, y además antes de destruir el componente totalmente, se ejecuta el hook ngOnDestroy.
Hooks ngOnChanges
Cuando se crea un componente lo primero que se ejecuta es el constructor de la clase del componente. Ahora bien, esto es totalmente normal en otros ámbitos. La creación de una nueva instancia de clase, así que realmente constructor no es un hook de angular.
ngOnChanges solo revisa los cambios de una propiedad input, esto es, todas las propiedades a las que se les aplica el decorador @input([alias]), que es la manera en que bindeamos o enlazamos propiedades de un componente padre a otro hijo usando esta sintaxis [habilidad]="expresion". Este patrón, de padre a hijo, nos permite obtener un mejor rendimiento en la detección de cambios entre componentes. Es por eso que en el código de los ejemplos siempre se utiliza un componente padre y un componente hijo. Los cambios se actualizan de padre a hijo.
En el ejemplo tenemos dos propiedades enlazadas [persona]="persona"and [habilidad]="habilidad", si cambiamos el valor de habilidad se dispara la ejecución de ngOnChanges en el componente hijo, sin embargo la propiedad persona.name no dispara el hook, esto pasa porque la detección de cambios comprueba la referencia de la propiedad persona y lo que se modifico fue la propiedad persona.name, por lo que la referencia al objeto persona nunca cambió.
Cada vez que se detecta un cambio, ngOnChanges recibe un objeto, el cual contiene todas las propiedades que cambiaron, y cada una de estas es de tipo SimpleChange conteniendo el valor anterior previousValue y el valor actual currentValue.
ngOnChanges puede detectar cambios en más de una propiedad @Input(), por lo que es muy útil para realizar múltiples operaciones en la información, como definir valores predeterminados, validar datos, transformarlos antes de ser utilizados por el componente y/o antes de ser visualizados por el usuario.
Hooks ngOnInit y ngOnDestroy
Hook ngOnInit
El hook ngOnInit se ejecuta una sola vez después de ngOnChanges y no se vuelve a ejecutar en el resto de vida del componente.
Una directiva puede tener hooks, esto se debe a que un componente es un tipo de directiva que tiene una plantilla html. Es decir, un componente es una directiva.
Dado que ngOnInit se ejecuta una sola vez después de ngOnChanges, es un buen lugar para:
Agregar inicializaciones complejas.
Como algún proceso asíncrono
Obtener de un servicio datos para uso en el componente
Subscribirse a un objeto para ser notificado de cambios, como los observables de RxJs, escuchar eventos del DOM
Etcétera.
Configuración de inicio debido a que ya se tienen los valores de las propiedades @inputs() gracias al hook ngOnChanges.
Cada vez que se presiona el botón Agregar Persona el hook ngOnInit se ejecuta, y cuando presionas el botón Resetear se ejecuta el hook ngOnDestroy justo antes de destruir a las elementos personas.
Hook ngOnDestroy
En este hook del ciclo de vida de un componente debería de ir todo el código de limpieza de un componente, justo antes de destruirlo.
También es un buen momento para notificar a otros componentes que va a ser destruido.
Es un buen punto donde liberar memoria, darse de baja de los Observadores como RxJS y los eventos del DOM. Detener los timers, dar de baja todos los callbacks enlazados a servicios. En general todo lo que consuma memoria y tiempo de ejecución.
Hook ngDoCheck
Este Hook del ciclo de vida de un componente se ejecuta después de cualquier ejecución de ngOnChange, y despues de ngOnInit, pero también se ejecuta después de eventos que pueden producir cambios, como por ejemplo el blur y focus de los inputs.
Dado que se ejecuta demasiadas veces, es muy costoso utilizar este hook, así que se debe usar con cuidado.
Para crear este ejemplo simplemente se implementó el método ngDoCheck en el componente hijo del código del hook ngOnChanges. Puedes probar cambiando datos y veras la ejecuciones de la función ngDoCheck.
ngOnChanges NO se ejecuta cuando modificamos una propiedad que no es un @input(), como pasa con la propiedad name of the object person, pero si se ejecuta el hook ngDoCheck. Puede ser útil para detectar cambios internos del componente, pero recuerda que tiene un costo alto de ejecución si deseas detectar muchas propiedades NO @inputsde tu componente.
También tenemos un elemento input dentro del componente hijo que esta enlazado a la propiedad [habilidad], esta es un @input, pero el cambio se realiza dentro del componente hijo, el componente padre no se entera de este cambio, por lo que aunque ngDoCheck se ejecuta, ngOnChanges no lo hace. Recuerda, la detección de cambios entre componentes se realiza de manera unidireccional, de padre a hijo.
Hooks AfterContentInit y AfterContentChecked
ngAfterContentInit se ejecuta una vez después del primer ngDoCheck y no se vuelve a ejecutar en todo el resto de vida del componente. ngAfterContentChecked se ejecuta después de cualquier ejecución de ngDoCheck en todo la vida del componente. Ambos se ejecutan después de que angular proyecta contenido externo en el componente.
Este contenido externo es proporcionado por el usuario del componente, similar a lo que se hace con el Light DOM de los componentes web nativos.
A lo anterior Angular le llama Proyección de contenido (Content projection), en AngularJS se conoce como transclusión. Para proyectar el contenido en el componente, se debe utilizar el tag <ng-content></ng-content>, esta etiqueta sería análoga a la etiqueta <slot> de los componenes web nativos.
Dentro del método ngAfterContentChecked se debe poder acceder al modelo o variables del contenido proyectado, para esto se debe utilizar el decorador @ContentChild([TipoDeHijo]), lo puedes ver en el archivo /app/after-content/after-content-child.component.ts.
// Para buscar contenido de tipo 'ChildComponent'(etiqueta lch-child)@ContentChild(ChildComponent) contentChild: ChildComponent;
Hooks AfterViewInit y AfterViewChecked
Estos hooks son muy similares a ngAfterContentInit and ngAfterContentChecked, solo que se invocan después de ngAfterContentChecked, siguiendo el mismo patron, ngAfterViewInit se invoca una sola vez después del primer ngAfterContentChecked, y no se vuelve a invocar.
ngAfterViewChecked, se ejecuta después de cualquier invocación de ngAfterContentChecked, la diferencia entre ngAfterContentChecked es que estos hooks marcan el final de la composición de la vista de un componente y se define dentro del componente mismo, no desde el exterior, como vimos con ngAfterContentChecked and ng-content, por esta razón tiene similitud con el Shadow DOM de los componentes web nativos.
Si revisas el código del /app/after-view/after-view-child.component.ts, para acceder al modelo o variables de la vista interna (Vista de hijos o Child View), debemos utilizar el decorator @ViewChild([TipoDeHijo]):
// Para buscar view childs del tipo ChildComponent@ViewChild(ChildComponent) viewChild: ChildComponent;
Otra cosa distinta a ngAfterContentChecked es que en ngAfterViewChecked no podemos cambiar el valor de inmediato de la propiedad comment enlazada con la vista, si lo haces, te saldrá un error como el siguiente:
Mistake:ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value:''. Current value:'Es un nombre muy grande'.
El error se debe que esté ultimo hook se ejecuta al final del ciclo de vida, entonces debe volver a pasar por ngOnChanges either ngDocheck para volver a renderizar la vista actualizada. La solución es actualizar la propiedad comment en una futura iteración del loop de Javascript. El setTimeout de this.logger.thick_then recibe una función, la cual se agrega a la cola de callbacks de javascript para ser escogida en una futura iteración del loop y esto le da el tiempo suficiente a Angular para actualizar la vista correctamente.
EN 
ES_MX