Diseño de Aplicaciones Web Basadas en Arquitectura de Capas Usando La Librería Redux

Universidad Mayor de “San Simón”
Facultad de Ciencias y Tecnología
Diseño de Aplicaciones Web basadas en Arquitectura de
Capas usando la Librería Redux

Elaborado por: Miguel Angel López Peredo
Carrera: Ingeniería de Sistemas
Tutor: Ing. Edson Ariel Terceros Torrico
Fecha: Septiembre de 2018
Cochabamba – Bolivia
2
A mi madre y a mi hijo, con mucho
amor y cariño les dedico todo mi
esfuerzo y trabajo puesto para la
realización de esta monografía

3
Agradecimientos:
A Dios porque está conmigo en cada paso que

doy, cuidándome y dándome fortaleza para
continuar.
A mi madre, quien a lo largo de mi vida ha

velado por mi bienestar y educación siendo mi
apoyo en todo momento.
A Mi hijo, por ser mi motor de continua

superación.
A mi hermana, por su apoyo incondicional que

me ha ayudado y llevado hasta donde estoy
ahora.
A mis hermanos, por sus consejos y

experiencias.
A Sigrid, por su confianza para lograr un

objetivo más en mi vida.
A Claudia Ossio, por su constante apoyo en el

Diplomado.
Al Ing. Edson Terceros, por su paciencia y

comprensión.
A mis amigos, por sus enseñanzas y consejos

para seguir superándome.
4
TABLA DE CONTENIDO
Resumen.......................................................................................................................................... 8
Introducción .................................................................................................................................. 10
1. Generalidades..................................................................................................................... 12
1.1 Antecedentes Generales.............................................................................................. 12
1.2 Antecedentes Específicos ........................................................................................... 13
2. Metodología ....................................................................................................................... 14
3. Subtemas ............................................................................................................................ 14
3.1 Angular (Capas, Servicios y Componentes ................................................................ 14
3.1.1 Módulos............................................................................................................... 16
3.1.2 Componentes ........................................................................................................... 17
3.1.3 Plantillas, directivas y enlace de datos................................................................... 17
3.1.4 Servicios e inyección de dependencia ..................................................................... 18
3.1.5 Enrutamiento........................................................................................................... 19
3.2 Modelo Vista Vista Modelo (MVVM) ............................................................................. 20
3.2.1 Modelo .................................................................................................................... 22
3.2.2 Vista ........................................................................................................................ 23
3.2.3 Vista Modelo ........................................................................................................... 24
3.3 Flux ................................................................................................................................... 25

5
3.3.1 Vista ........................................................................................................................ 27
3.3.2 Almacén................................................................................................................... 27
3.3.3 Acciones .................................................................................................................. 27
3.3.4 Despachador ........................................................................................................... 28
3.3.5 Implementaciones de Flux ...................................................................................... 29
3.4 Redux ................................................................................................................................ 29
3.4.1 Arquitectura Redux y sus Principales Características ........................................... 32
3.4.2 Principios de Redux ................................................................................................ 37
3.5 NgRx ................................................................................................................................. 40
3.6 Caso Práctico .................................................................................................................... 42
3.6.1 Instalación............................................................................................................... 42
3.6.2 Creación del Modelo de Datos ............................................................................... 42
3.6.3 Creación de las Acciones ........................................................................................ 42
3.6.4 Creación de los Reductores .................................................................................... 43
3.6.5 Creación del App State ........................................................................................... 44
3.6.6 Importar el Almacén Ngrx ...................................................................................... 44
3.6.7 Creación del Componente Customer ...................................................................... 45
3.6.8 Creación del Componente Customer Details ......................................................... 46

6
3.6.9 Creación del Componente Customer List ............................................................... 47
3.6.10 Importación de los Componentes al App Component............................................. 48
3.6.11 Vista de Interfaz de Usuario ................................................................................... 49
Conclusiones ................................................................................................................................. 50
Bibliografía ................................................................................................................................... 52
7
TABLA DE CUADROS, GRAFICOS Y FIGURAS
Figura 1: Descripción de la arquitectura MVVM. ........................................................................ 22
Figura 2: Arquitectura del Patrón Flux. ........................................................................................ 26
Figura 3: Comparativa de Componentes con y sin Redux. ........................................................... 32
Figura 4: Patrón Redux y sus componentes. ................................................................................. 33
Figura 5: Ejemplo de Objeto de Acción. ...................................................................................... 34
Figura 6: Ejemplo de una función que crea un objeto de Acción. ................................................ 34
Figura 7: Implementación simple de un Reductor. ....................................................................... 36
Figura 8: Visualización del código de un despachador. ............................................................... 38
Figura 9: Declaración de cambios con funciones puras................................................................ 39
Figura 10: Interfaz de Usuario Customers usando Ngrx y Angular. ............................................ 49

8
RESUMEN
Los datos de las aplicaciones web fluyen en una sola dirección, permitiendo tener mayor control
y haciendo fácil la corrección y detección de errores; sin embargo, uno de los principales
problemas, es el flujo de datos bidireccional, donde un cambio en la interfaz dispara múltiples
eventos que afectan a múltiples vistas generando efectos en cascada, haciendo muy difícil
depurar y resolver un problema.
El resultado de la presente monografía ayudará a la implementación y el uso del patrón Redux de
arquitectura Flux para gestionar el flujo de datos en la capa de presentación de aplicaciones
empresariales que tienden a crecer exponencialmente.
Una aplicación a gran escala, tiende a que la gestión del estado de la aplicación pueda
convertirse en un problema a medida que esta crece. El estado de la aplicación incluye respuestas
del servidor, datos en caché y datos que aún no se han conservado en el servidor.
Redux predice las mutaciones de estado, sin perder las ventajas de rendimiento Asíncrono, lo
hace imponiendo ciertas restricciones sobre cómo pueden ocurrir las actualizaciones, estas
restricciones hacen aplicaciones predecibles y fáciles de probar.
Las principales características de arquitectura utilizando el patrón Redux son:

9
● Acciones: son objetos planos de Java, con al menos una propiedad que indica el tipo de
acción.
● Creador de acciones: son funciones que devuelven una acción
● Reductores: es una función que recibe el estado actual y devuelve un nuevo estado.
● Almacenes: reciben acciones para pasarlas por los middlewares, para luego pasarlas por
reductores que calculan el nuevo estado y lo guardan.
Igualmente, Redux se basa en tres principios fundamentales: única fuente de verdad, el estado es
solo de lectura y los cambios se hacen en funciones puras.
Aplicando Redux para el desarrollo de una aplicación, permitirá que la misma pueda ser
escalable.
10
INTRODUCCIÓN
En un principio la web estaba compuesta por páginas estáticas y documentos; entre otros, que el
usuario utilizaba para consulta y descarga, sin embargo, conforme al mayor uso del internet el
uso de la web tuvo que ir transformándose a las necesidades de un número creciente de usuarios;
de esta forma el siguiente paso fue la creación de páginas dinámicas que pudieran mostrar
información dinámica, es decir generando la misma a partir de los datos de petición.
En el año 1998, Netscape Navigator anuncia la nueva tecnología JavaScript, la cual permite que
el contenido de una página web cambie de forma dinámica, si bien se aceptaban scripts en
Netscape desde 1997, JavaScript vino a revolucionar el uso de las aplicaciones web1.
A finales de la década de los 90, las aplicaciones web fueron creciendo exponencialmente, sobre
todo para usos empresariales, por lo que las aplicaciones web de hoy en día son mucho más
grandes, lo cual implica un incremento de la complejidad. Esa complejidad hace que tareas como
la comunicación entre distintos componentes de la interfaz y la gestión del estado sigan un flujo
de datos complejo que por el tamaño se hace muy difícil de manejar.
En general los datos de una aplicación web fluyen en una sola dirección, lo cual permite tener
más control de la aplicación, haciendo fácil detectar, corregir errores y lograr llevar la aplicación
a un estado anterior o siguiente sin muchas complicaciones.
1
Ver https://www.sutori.com/story/historia-de-las-aplicaciones-web .
11
Sin embargo, uno de los principales problemas, es el flujo de datos bidireccional, donde un
cambio en la interfaz dispara múltiples eventos que afectan a múltiples vistas generando efectos
en cascada, haciendo muy difícil depurar y resolver un problema.
Por ejemplo, el problema se presenta cuando una aplicación web se vuelve muy grande y la
complejidad del mismo puede volverse exponencial cada vez que se intenta adicionar una nueva
característica, haciendo que el código sea “frágil e impredecible”.
Una solución a este problema es el uso del patrón Redux, que ayuda a la gestión del estado de la
aplicación y estado de cada uno de los componentes. Al hacer uso de este concepto, se deja el
control del estado en un único objeto llamado almacén, que es a su vez el único capaz de
modificarlo.
12
1. Generalidades
1.1 Antecedentes Generales
Flux es una arquitectura diseñada por Facebook junto con una librería para vistas. Se enfoca en
crear flujos de datos explícitos y entendibles, lo cual hace más sencillo seguir los cambios en el
estado de la aplicación y por ende los errores más fáciles de encontrar y corregir.
Para comprender mejor la arquitectura Flux, se compara con MVC o Modelo-Vista-Controlador,
uno de los patrones más utilizados en el desarrollo de aplicaciones. En MVC el controlador es
responsable de coordinar los cambios en uno o más modelos, lo hace mediante llamadas a
métodos en los modelos. Cuando los modelos cambian, se notifican las vistas, las cuales a su vez
leen los nuevos datos del modelo y se actualizan de acuerdo a esos cambios para que el usuario
pueda ver los nuevos datos o estado.
Conforme la aplicación crece y se agregan más controladores, modelos y vistas las dependencias
se vuelven más complejas.
Cuando el usuario interactúa con la interfaz gráfica, múltiples ramas de código son ejecutadas y
encontrar errores o correr pruebas sobre el estado de la aplicación, se vuelve una tarea muy
difícil, en la que básicamente se tiene que tratar de adivinar en cuál de todos los puntos se
encuentra el error. En los peores casos, una interacción causa actualizaciones adicionales en
cascada haciendo la tarea aún más dura.

13
Flux evita este diseño en favor de un flujo de datos en una sola dirección. Todas las interacciones
dentro de una vista llaman un “creador de acciones” que a su vez llama al “despachador” de tipo
Singleton, que es responsable de emitir un evento de tipo “acción” al cual los “almacenes” se
pueden subscribir. Estos “almacenes” responden a la acción y se auto actualizan.
Flux evita este diseño en favor de un flujo de datos en una sola dirección. Todas las
interacciones dentro de una vista llaman un “creador de acciones” que a su vez llama el
“despachador” de tipo Singleton que es responsable de emitir un evento de tipo “acción” al cual
los “almacenes” se pueden subscribir. Estos “almacenes” responden a la acción y se auto
actualizan.
1.2 Antecedentes Específicos
Redux, es un patrón de arquitectura de datos que permite manipular el estado de la aplicación de
una forma predecible. Está creado para disminuir el número de relaciones entre los componentes
de la aplicación y conservar un flujo de datos asequible.
Su creación comenzó en la Comunidad de React para mejorar Flux, paso a convertirse en un
patrón transversal que se adapta a cualquier tipo de librería o framework del lado del cliente.
Con tan solo 2 KB, Redux es una librería muy liviana y se puede ejecutar a la perfección por el
motor de JavaScript. Para tener una idea de su repercusión, empresas como Netflix lo han
adoptado para sus proyectos.

14
2. Metodología
A continuación, se describen los métodos de investigación a ser utilizados:
● Método Bibliográfico, debido a que se realizara la lectura, compilación de libros,
documentación oficial relacionados al tema de estudio.
● Método Analítico, debido a que se procederá a revisar y analizar ordenadamente
documentos relacionados al tema de estudio, para la redacción del presente trabajo.
● Método Empírico o de Campo, debido a que se utilizaran ejemplos de aplicación o
experiencias observadas.
3. Subtemas
Las aplicaciones web mejoran su mantenibilidad y organización de arquitectura cuando se aplica
la arquitectura de separación de capas y se mejora el flujo de datos de la aplicación mediante el
patrón de arquitectura Flux con su librería Redux.
3.1 Angular (Capas, Servicios y Componentes
Los módulos permiten organizar funcionalidad de los subsistemas, dentro de los cuales existen
componentes cuyo fin es la reutilización y separación de intereses que modelan componentes de
la interfaz, los cuales tienen plantillas asociadas que ayudan a separar la lógica del negocio de
vista de la presentación del DOM, estos componentes interactúan con lógica del negocio
mediante servicios que se encargan de realizar dicha interacción, son las principales
características de Angular.
15
Angular es una plataforma y un Framework para crear aplicaciones cliente en HTML y
TypeScript. Angular está escrito en TypeScript. Implementa funcionalidad central y opcional
como un conjunto de bibliotecas de TypeScript que importa a sus aplicaciones. (Angular, 2018)
Los bloques de construcción básicos de una aplicación angular son NgModules, que
proporcionan un contexto de compilación para los componentes. NgModules recopila código
relacionado en conjuntos funcionales; una aplicación angular está definida por un conjunto de
NgModules. Una aplicación siempre tiene al menos un módulo raíz que habilita el arranque, y
generalmente tiene muchos más módulos de características.
Los componentes definen vistas, que son conjuntos de elementos de pantalla que Angular puede
elegir y modificar según la lógica y los datos del sistema.
Los componentes usan servicios que proporcionan una funcionalidad específica, que no está
directamente relacionada con las vistas. Los proveedores de servicios pueden inyectarse en
componentes como dependencias, haciendo que su código sea modular, reutilizable y eficiente.
Tanto los componentes, como los servicios son simplemente clases, con decoradores que marcan
su tipo y proporcionan metadatos que le dicen a Angular cómo usarlos.

16
Los metadatos de una clase de componente lo asocian con una plantilla que define una vista. Una
plantilla combina HTML común con directivas angulares y marcado de enlace que permiten a
Angular modificar el HTML antes de representarlo para su visualización.
Los metadatos de una clase de servicio proporcionan la información que Angular necesita para
ponerla a disposición de los componentes a través de la inyección de dependencia (DI).
Los componentes de una aplicación generalmente definen muchas vistas, organizadas
jerárquicamente; Angular proporciona el servicio enrutador para ayudar a definir rutas de
navegación entre vistas a su vez el enrutador proporciona sofisticadas capacidades de navegación
en el navegador.
3.1.1 Módulos
Los NgModules difieren y complementan los módulos de JavaScript (ES2015). Un NgModule
declara un contexto de compilación para un conjunto de componentes que está dedicado a un
dominio de aplicación, un flujo de trabajo o un conjunto de capacidades estrechamente
relacionadas. Un NgModule puede asociar sus componentes con código relacionado, como
servicios, para formar unidades funcionales. (Angular, 2018)
Cada aplicación angular tiene un módulo raíz, denominado de manera convencional AppModule,
que proporciona el mecanismo de arranque que inicia la aplicación. Una aplicación generalmente
contiene muchos módulos funcionales.

17
Al igual que los módulos de JavaScript, NgModules puede importar funcionalidades de otros
NgModules y permitir que otros NgModules exporten y utilicen su propia funcionalidad.
Organizar el código en distintos módulos funcionales ayuda a gestionar el desarrollo de
aplicaciones complejas y al diseño para su reutilización. Además, esta técnica permite
aprovechar la carga diferida, es decir, cargar módulos bajo demanda, para minimizar la cantidad
de código que se debe cargar al inicio.
3.1.2 Componentes
Cada aplicación angular tiene al menos un componente, el componente raíz que conecta una
jerarquía de componentes con el modelo de objetos del documento de página (DOM) (Angular,
2018).
Cada componente define una clase que contiene datos y lógica de la aplicación, y está asociada a
una plantilla HTML que define una vista que se mostrará en un entorno objetivo.
El decorador @Component () identifica la clase inmediatamente debajo de él como un
componente y proporciona la plantilla y los metadatos específicos de los componentes
relacionados.
3.1.3 Plantillas, directivas y enlace de datos
Una plantilla combina HTML con marcado angular que puede modificar elementos HTML antes
de que se muestren, las directivas de plantilla proporcionan lógica de programa, y el marcado

18
vinculante conecta los datos de su aplicación y el DOM. (Angular, 2018) Hay dos tipos de enlace
de datos:
● El enlace de eventos, que permite que su aplicación responda a la entrada del usuario en
el entorno objetivo, actualizando los datos de su aplicación.
● El enlace de propiedad, que permite interpolar valores que se computan a partir de los
datos de su aplicación en el HTML.
Antes de que se muestre una vista, Angular evalúa las directivas y resuelve la sintaxis de enlace
en la plantilla para modificar los elementos HTML y el DOM, según los datos y la lógica de su
programa. Angular admite el enlace de datos bidireccional, lo que significa que los cambios en el
DOM, como las opciones del usuario, también se reflejan en los datos de su programa.
Sus plantillas pueden usar tuberías para mejorar la experiencia del usuario al transformar los
valores para su visualización. Por ejemplo, el uso de tuberías para mostrar fechas y valores de
moneda que sean apropiados para la configuración regional de un usuario. Angular proporciona
tuberías predefinidas para transformaciones comunes, y también puede definir sus propias
tuberías.
3.1.4 Servicios e inyección de dependencia
Para los datos o la lógica que no está asociada a una vista específica y que se desea compartir
entre los componentes, crea una clase de servicio. Una definición de clase de servicio va
precedida inmediatamente por el decorador @Injectable ().

19
El decorador proporciona los metadatos que permiten que su servicio se inyecte en los
componentes del cliente como una dependencia.
La inyección de dependencia (DI) le permite mantener sus clases de componentes delegadas y
eficientes. No obtienen datos del servidor, validan la entrada del usuario o inician sesión
directamente en la consola; delegan tales tareas a los servicios. (Angular, 2018)
3.1.5 Enrutamiento
El enrutamiento en Angular (Router NgModule) proporciona un servicio que le permite definir
una ruta de navegación entre los diferentes estados de aplicación y ver jerarquías en su
aplicación. (Angular, 2018).
Se basa en las convenciones de navegación del navegador:
● Ingresar una URL en la barra de direcciones y el navegador navega a la página
correspondiente.
● Hacer clic en los enlaces en la página y el navegador navega a una nueva página.
● Hacer clic en los botones para retroceder y avanzar del navegador y el navegador navega
hacia atrás y hacia adelante por el historial de las páginas que se visitó.
El enrutador mapea rutas de tipo URL a vistas en lugar de páginas, cuando un usuario realiza una
acción, como hacer clic en un enlace, que cargaría una página nueva en el navegador, el
enrutador intercepta el comportamiento del navegador y muestra u oculta las jerarquías de vista.
Si el enrutador determina que el estado actual de la aplicación requiere una funcionalidad
particular, y que el módulo que lo define no se ha cargado, el enrutador puede cargar el módulo a
demanda.
20
El enrutador interpreta una URL de enlace según las reglas de navegación de la vista de su
aplicación y el estado de los datos. Se puede navegar a nuevas vistas cuando el usuario hace clic
en un botón o selecciona desde un cuadro desplegable, o en respuesta a algún otro estímulo de
cualquier fuente. El enrutador registra la actividad en el historial del navegador, por lo que los
botones para avanzar y retroceder también funcionan.
Para definir las reglas de navegación, se procede a asociar las rutas de navegación con sus
componentes. Una ruta utiliza una sintaxis similar a una URL que integra los datos de su
programa, de forma muy parecida a como la sintaxis de la plantilla integra sus vistas con los
datos de su programa. A continuación, puede aplicar la lógica del programa para elegir qué vistas
mostrar u ocultar, en respuesta a la entrada del usuario y sus propias reglas de acceso.
3.2 Modelo Vista Vista Modelo (MVVM)
Las mejoras que aporta el patrón MVVM se basan en la separación de las interfaces de usuario
de la lógica de negocio y sus principales componentes son: modelo vista vista modelo.
Modelo Vista Vista Modelo MVVM, es un patrón arquitectónico basado en MVC y MVP, que
intenta separar más claramente el desarrollo de las interfaces de usuario (UI) de la lógica de
negocios y el comportamiento en una aplicación., como se puede apreciar en la Figura 1. Con
este fin, muchas implementaciones de este patrón hacen uso de enlaces de datos declarativos
para permitir una separación del trabajo en Vistas desde otras capas. Esto facilita la interfaz de
usuario y el trabajo de desarrollo que ocurre casi simultáneamente dentro de la misma base de
21
código. Los desarrolladores de UI escriben enlaces a la Vista Modelo dentro de su marcado de
documento (HTML), donde los desarrolladores que trabajan en la lógica de la aplicación
mantienen el Modelo y el Modelo de Vista. (Microsoft, 2018)
MVVM fue originalmente definido por Microsoft para su uso con Windows Presentation
Foundation (WPF) y Silverlight, habiendo sido anunciado oficialmente en 2005 por John
Grossman en una publicación de blog sobre Avalon (el nombre clave de WPF). También
encontró cierta popularidad en la comunidad de Adobe Flex como alternativa al simple uso de
MVC. Antes de que Microsoft adoptara el nombre de MVVM, sin embargo, hubo un
movimiento en la comunidad para pasar de MVP a MVPM: Modelo Vista Presentación Modelo.
(Microsoft, 2018)
En los últimos años, MVVM se ha implementado en JavaScript en forma de marcos estructurales
como KnockoutJS, Kendo MVVM y Knockback.js, con una respuesta positiva general de la
comunidad.
22
Fuente: (Montemagno, 2018)
Figura 1: Descripción de la arquitectura MVVM.
A continuación, se describen los componentes de MVVM:
3.2.1 Modelo
Al igual que con otros miembros de la familia MV *, el Modelo en MVVM representa
información o datos específicos del dominio con los que nuestra aplicación estará trabajando. Un
ejemplo típico de datos específicos del dominio puede ser una cuenta de usuario (por ejemplo,
nombre, avatar, correo electrónico) o una pista de música (por ejemplo, título, año, álbum).
Los modelos contienen información, pero generalmente no manejan el comportamiento. No
formatean la información ni influyen en cómo aparecen los datos en el navegador, ya que no es

23
su responsabilidad. En cambio, el formato de los datos es manejado por la Vista, mientras que el
comportamiento de la lógica de negocio debe ser encapsulada en otra capa que interactúa con el
Modelo: Vista Modelo. La única excepción a esta regla tiende a ser la validación y se considera
aceptable que los Modelos validen los datos que se utilizan para definir o actualizar modelos
existentes. (Microsoft, 2018)
3.2.2 Vista
Al igual que con MVC, la Vista es la única parte de la aplicación con la que los usuarios
realmente interactúan. Son una interfaz de usuario interactiva que representa el estado de un
Vista Modelo. En este sentido, la vista se considera activa en lugar de pasiva, pero esto también
es cierto para las vistas en MVC y MVP.
En MVC, MVP y MVVM una vista también puede ser pasiva. Una vista pasiva solo muestra una
pantalla y no acepta ninguna entrada del usuario, dicha vista también puede no tener un
conocimiento real de los modelos en nuestra aplicación y podría ser manipulada por un
presentador. La vista activa de MVVM contiene enlaces de datos, eventos y comportamientos
que requieren una comprensión del Vista Modelo. Aunque estos comportamientos se pueden
asignar a las propiedades, la Vista sigue siendo responsable de manejar los eventos desde el
Vista Modelo. (Garofalo, 2011, pp. 151,152).
Es importante recordar que la Vista no es responsable por el manejo del estado; lo mantiene
sincronizado con la Vista Modelo.

24
3.2.3 Vista Modelo
Vista Modelo, puede considerarse un Controlador especializado que actúa como un convertidor
de datos. Cambia la información del Modelo a información de Vista, pasando comandos de la
Vista al Modelo. Por ejemplo, imaginemos que tenemos un modelo que contiene un atributo de
fecha en formato Unix (por ejemplo, 1333832407), en lugar de que nuestros modelos conozcan
la fecha de visualización del usuario (p. Ej., 04/07/2012 a las 5:00 p.m.), donde sería necesario
convertir el atributo a su formato de visualización, nuestro modelo simplemente contiene el
formato sin formato de los datos, nuestra vista contiene la fecha formateada y nuestro modelo de
vista actúa como intermediario entre los dos.
En este sentido, Vista Modelo podría considerarse más un Modelo que una Vista, pero maneja la
mayor parte de la lógica de visualización de la Vista. Vista Modelo también puede exponer
métodos para ayudar a mantener el estado de la Vista, actualizar el modelo basado en la acción
en una Vista y desencadenar eventos en la Vista.
En resumen, Vista Modelo se encuentra detrás de nuestra capa de interfaz de usuario, expone los
datos que necesita una Vista (de un Modelo) y se puede ver como la fuente a la que van nuestras
Vistas para los datos y las acciones.
Nuestras Vistas manejan sus propios eventos de interfaz de usuario, asignándolos a la Vista
Modelo según sea necesario, los modelos y atributos en la Vista Modelo se sincronizan y
actualizan a través de enlace de datos bidireccional. Vista Modelo no solo expone los atributos
25
del Modelo, sino también el acceso a otros métodos y funciones, como la validación. Los
disparadores (desencadenadores de datos) también nos permiten reaccionar aún más a los
cambios en el estado de nuestros atributos de modelo; si bien puede parecer que Vista Modelo es
completamente responsable del Modelo en MVVM, hay algunas sutilezas con esta relación que
vale la pena mencionar. Vista Modelo puede exponer los atributos de un Modelo o Modelos a
efectos de enlace de datos y también puede contener interfaces para recuperar y manipular
propiedades expuestas en la vista. (Garofalo, 2011, pp. 161,162).
3.3 Flux
Flux, es la arquitectura de aplicaciones que se usa para construir aplicaciones web del lado del
cliente. Utilizando un flujo de datos unidireccional. Los datos de una aplicación con la
arquitectura flux, fluyen en una sola dirección, lo cual nos permite tener más control de nuestra
aplicación haciendo fácil detectar y corregir errores, el concepto fue creado para mejorar los
puntos débiles y la dificultad de controlar los cambios en la capa de presentación del patrón
MVC (o MVVM).
El patrón MVC para la capa de presentación, empezó a ser necesario cuando las aplicaciones
web empezaron a hacerse más grandes y con librerías como jQuery o el propio Vanilla
JavaScript se hacían difíciles de manejar. Por eso nacieron frameworks como Backbone, Ember
y/o Angular. (Dinkevich, 2017, pp. 6-8)
Todos ellos siguen una arquitectura Modelo-Vista-Controlador, o algo parecido (MVVM, MV*).
Haciendo más sencillo el manejo de datos en aplicaciones web con cierto grado de complejidad.
26
Flux nació desde Facebook por un problema que se les presentaba al tener una comunicación
bidireccional entre los modelos y los controladores, haciéndoles muy difícil poder depurar y
rastrear errores.
Flux propone una arquitectura en la que el flujo de datos es unidireccional, descrito en la Figura
2. Los datos viajan desde la vista por medio de acciones y llegan a un Store desde el cual se
actualizará la vista de nuevo.
Fuente: (Facebook, 2018)
Figura 2: Arquitectura del Patrón Flux.
Teniendo un único camino, y un sitio donde se almacena el estado de la aplicación, es más
sencillo depurar errores y saber que está pasando en cada momento.
Flux es un patrón de diseño o forma de "arquitecturar" una aplicación web, en concreto la forma
en la que se manejan los datos o estado de la aplicación (datos de un usuario, datos recogidos a
27
partir de un API REST o WebService, etc.), no se trata de una librería ni framework. (Bugl,
2017, p. 57).
Al igual que un patrón MVC está formado por un Modelo, una Vista y un Controlador, en Flux
tenemos distintos actores:
3.3.1 Vista
La vista serían los componentes web, ya sean construidos nativamente, con Polymer, Angular,
React.
3.3.2 Almacén
Almacén, sería lo más parecido al modelo de la aplicación. Guarda los datos/estado de la
aplicación y en Flux puede haber varias.
No hay métodos en el almacén que permitan modificar los datos en ella, eso se hace a través de
despachadores y acciones.
3.3.3 Acciones
Una acción es simplemente un objeto JavaScript que indica una intención de realizar algo y que
lleva datos asociados si es necesario. (Bugl, 2017, p. 74)
Por ejemplo, si tenemos una aplicación tipo carrito de la compra, y añadimos un ítem al carrito,
la acción que representaría esto sería:
{
28
type: 'ADD_ITEM',
item: item
3.3.4 Despachador
Las acciones como la anterior son enviadas a un despachador que se encarga de dispararla o
propagarla hasta el almacén. La vista es la que se encarga de enviar las acciones al despachador.
Un despachador no es más que un mediador entre el almacén o almacenes y las acciones. Sirve
para desacoplar la Store de la vista, ya que así no es necesario conocer que Store maneja una
acción concreta. (Bugl, 2017, pp. 102,103)
En Resumen, el patrón Flux sigue el siguiente recorrido:
● La vista, mediante un evento envía una acción con la intención de realizar un cambio en
el estado
● La acción contiene el tipo y los datos (si los hubiere) y es enviada al despachador.
● El despachador propaga la acción al Store y se procesa en orden de llegada.
● El almacén recibe la acción y dependiendo del tipo recibido, actualiza el estado y notifica
a las vistas de ese cambio.
● La vista recibe la notificación y se actualiza con los cambios.
● Todo en un único sentido.

29
3.3.5 Implementaciones de Flux
Existen numerosas implementaciones de este patrón de desarrollo en JavaScript. Muchas de ellas
ya no están actualizadas y poco a poco una de ellas se fue posicionando como referencia.
Se cita las siguientes librerías:
● Reflux
● McFly
● Marty.js
● Delorean
● Fluxxor
● Lux.js
● Fluxible
● Omniscent
● Redux
3.4 Redux
Redux, es una librería que implementa el patrón de diseño Flux, que se encarga de emitir
actualizaciones de estado en respuesta a acciones. En lugar de modificar directamente el estado,
la modificación se maneja a través de objetos sencillos llamados acciones. Luego se escribe una
función especial llamada reductor para decidir cómo cada acción transforma el estado de toda la
aplicación.
30
Una aplicación a gran escala, tiende a que la gestión del estado de la aplicación pueda
convertirse en un problema a medida que esta crece. El estado de la aplicación incluye respuestas
del servidor, datos en caché y datos que aún no se han conservado en el servidor. (Redux, 2018)
Además, el estado de la interfaz de usuario (UI) aumenta constantemente en complejidad, por
ejemplo, hoy en día; el enrutamiento a menudo se implementa en el cliente para no actualizar el
navegador y volver a cargar toda la aplicación.
El enrutamiento del lado del cliente es bueno para el rendimiento, pero significa que el cliente
debe tratar con más estados (en comparación con el uso del enrutamiento del lado del servidor).
Los conflictos e inconsistencias en estos diversos tipos de estado pueden ser difícil de tratar.
Gestionar todos estos estados se hace complicado y, si no se gestiona correctamente, el estado de
la aplicación puede crecer rápidamente fuera de control.
Como si todo esto no fuera lo suficientemente malo, nuevos requisitos, como actualizaciones
optimistas y la representación del lado del servidor, se vuelven necesarios, para poder
mantenerse al día con el aumento las demandas de rendimiento.
Este estado es difícil de tratar, porque se mezcla dos conceptos que pueden ser muy
impredecibles cuando se juntan:
● Asincronicidad, significa que los cambios pueden suceder en cualquier momento, de
forma asincrónica. Por ejemplo, un usuario presiona un botón que causa una solicitud del
31
servidor y puede no saber cuándo responde el servidor y, por motivos de rendimiento, no
queremos esperar la respuesta. Aquí es donde entra en juego la asincronía; actuamos en
una respuesta cada vez que ocurre, pero es impredecible cuando esto sucederá. (Bugl,
2017, p. 40)
● Mutación, significa cualquier cambio en el estado de la aplicación, como almacenar el
resultado de la respuesta del servidor en nuestro estado de aplicación o navegando a una
nueva página con el cliente, el enrutamiento, cambiaría el valor de la ruta actual, mutando
la aplicación estado. (Bugl, 2017, p. 40)
Redux intenta predecir las mutaciones de estado, sin perder las ventajas de rendimiento de
Asincronicidad, lo hace imponiendo ciertas restricciones sobre cómo pueden ocurrir las
actualizaciones, estas restricciones hacen aplicaciones predecibles y fáciles de probar. (Redux,
2018).
Una vez que un componente necesita compartir el estado con otro componente, con el que no
tiene una relación padre-hijo, las cosas comienzan a complicarse. En la Figura 3, se puede
visualizar ese problema. Una vez que un componente inicia un cambio de estado, este cambio
debe propagarse a todos los demás componentes que dependen de los datos modificados.
32
Fuente: (Redux, 2018)
Figura 3: Comparativa de Componentes con y sin Redux.
3.4.1 Arquitectura Redux y sus Principales Características
El siguiente grafico muestra los principales elementos de la arquitectura Redux, que ayudan a la
vez a comprender sus principales características.

33
Fuente: (Share, 2018)
Figura 4: Patrón Redux y sus componentes.
3.4.1.1Acciones (Actions)
Las Acciones son POJOs (Plain Old JavaScript Objects) con al menos una propiedad que indica
el tipo de acción y de ser necesario, otras propiedades indicando cualquier otro dato necesario
para efectuar la acción. Ver Figura 5. Normalmente se usa el formato definido en el Flux
Standard Action (FSA). (Marc Garreau, 2018, p. 8)

34
Fuente: (Dinkevich, 2017, p. 10)
Figura 5: Ejemplo de Objeto de Acción.
3.4.1.2Creador de Acciones (Action Creators)
Estas son simplemente funciones que pueden o no recibir parámetros y devuelven una acción (un
POJO), es muy buena idea, para evitar problemas de consistencia, programar una función por
cada tipo de acción y usarlas en vez de armar nuestros objetos a mano. Ver Figura 6. (Dinkevich,
2017, p. 504).
Figura 6: Ejemplo de una función que crea un objeto de Acción.

35
Debido a que normalmente son funciones puras son fáciles de testear. Luego de ejecutar nuestra
función, para poder despachar la acción, es simplemente llamar a la función dispatch().
3.4.1.3Reductores (Reducers)
Un reductor es una función pura que recibe el estado actual y una acción y devuelve el nuevo
estado. Como se describe en la Figura 7. (Marc Garreau, 2018, p. 9)
Es muy importante que se mantengan como funciones puras. Algunas cosas que no se debería
hacer en un reductor son:
● Modificar sus argumentos directamente (lo correcto es crear una copia)
● Realizar acciones con efectos secundarios como llamadas a una API o cambiar rutas
● Ejecutar funciones no puras como Date.now() o Math.random().
Que se mantengan puros, quiere decir que pasándole los mismos parámetros debería siempre
devolver el mismo resultado.

36
Figura 7: Implementación simple de un Reductor.
3.4.1.4Almacenes (Store)
A diferencia de muchas otras implementaciones de Flux, Redux tiene un único almacén que
contiene la aplicación información, pero sin lógica de usuario. El papel del almacén es recibir
acciones, pasarlas a través de todos los middlewares registrados, y luego usar reductores para
calcular un nuevo estado y guardarlo. Cuando recibe una acción que causa un cambio en el
estado, el almacén tienda notificará a todos los oyentes registrados, que se ha hecho un cambio al
estado. Esto permitirá varias partes del sistema, como la interfaz de usuario, para actualizarse de
acuerdo con el nuevo estado (Dinkevich, 2017, p. 99).
En resumen, las responsabilidades del Almacén se listan a continuación:
● Almacenar el estado global de la aplicación
● Dar acceso al estado mediante store.getState()

37
● Permitir que el estado se actualice mediante store.dispatch()
● Registrar listeners mediante store.subscribe(listener)
3.4.2 Principios de Redux
Redux puede ser descrito en tres principios fundamentales:
3.4.2.1Única Fuente de la Verdad
El estado de toda la aplicación está almacenado en un árbol guardado en un único almacén.
(Noring, 2018, p. 208)
Esto hace fácil crear aplicaciones universales, ya que el estado en el servidor puede ser
serializado y enviado al cliente sin ningún esfuerzo extra. Como un único árbol de estado
también hace más fácil depurar una aplicación; igualmente permite mantener el estado de la
aplicación en desarrollo, para un ciclo de desarrollo más veloz. Algunas funcionalidades que
históricamente fueron difíciles de implementar como, por ejemplo: Deshacer/Rehacer, se
vuelven triviales si todo tu estado se guarda en un solo árbol.
3.4.2.2 El Estado es Solo de Lectura
La única forma de modificar el estado es emitiendo una acción, un objeto describiendo que
ocurrió.
38
Esto te asegura que ni tu vista ni callbacks de red van a modificar el estado directamente, como
se muestra en la Figura 8. (Noring, 2018, p. 208).
En vez de eso, expresan un intento de modificar el estado, ya que todas las modificaciones están
centralizadas y suceden en un orden estricto, no hay que preocuparse por una carrera entre las
acciones. y como las acciones son objetos planos, pueden ser registrados, serializados y
almacenados para volver a ejecutarlos por cuestiones de depuración y pruebas.
Fuente: Elaboración Propia
Figura 8: Visualización del código de un despachador.
3.4.2.3 Los Cambios se Realizan con Funciones Puras
Para especificar como el árbol de estado es transformado por las acciones, se utilizan reductores
puros. (Noring, 2018, p. 210)
Los reductores son funciones puras que toman el estado anterior y una acción, y devuelven un
nuevo estado, como se puede apreciar en la Figura 9. Se debe devolver un nuevo objeto de
estado en vez de modificar el anterior. Inicialmente se puede empezar con un único reductor, y
39
mientras la aplicación crece, dividir en varios reductores pequeños que manejen partes
específicas del árbol de estado. Ya que los reductores son funciones puras, se puede controlar el
orden en que se ejecutan, pasar datos adicionales, o incluso hacer reductores reusables para
tareas comunes como paginación.
Figura 9: Declaración de cambios con funciones puras.

40
A diferencia de Flux, en Redux no existe el concepto de despachador. Esto es porque se basa en
funciones puras en vez de emisores de eventos, y las funciones puras son fáciles de componer y
no necesitan entidades adicionales para controlarlas.
Flux siempre fue descripto como (estado, acción) => estado. En ese sentido, Redux es una
verdadera arquitectura Flux, pero más simple gracias a las funciones puras.
Otra diferencia importante con Flux es que Redux asume que nunca se modifican los datos, se
puede usar objetos planos o arreglos para el estado y está perfecto, pero modificarlos dentro de
los reductores no es recomendable. Siempre se debería devolver un nuevo objeto, lo cual es
simple con la propuesta del operador spread, o con librerías como Inmutable.
Mientras que técnicamente es posible escribir reductores impuros que modifican los datos por
razones de rendimiento, no es aconsejable realizar dicha práctica. Además, características como
inmutabilidad no parecen causar problemas de rendimiento en aplicaciones reales, ya que, se
demostró que incluso se llega a perder la posibilidad de usar asignación en objetos, debido a que
sabes exactamente qué cambio gracias a los reductores puros. (Noring, 2018, p. 216)
3.5 NgRx
NgRx, es una colección de bibliotecas reactivas para angular, que contiene una implementación
de reducción y muchas otras bibliotecas útiles al ser una implementación de Redux hecha para
Angular, los conceptos como almacenes, creadores de acciones, acciones, selectores y reductores
41
son bien utilizados. Es una excelente manera de administrar el estado utilizando el patrón Redux
y mantener su aplicación escalable.
NgRx ayuda a crear aplicaciones más sólidas organizando mejor el estado de su aplicación, en
otras palabras, los datos de la aplicación. Sin una solución de administración del estado, tratar
con datos complejos en múltiples componentes puede ser bastante difícil de manejar y probar.
(Noring, 2018, pp. 238,239)
NgRx está compuesto de las siguientes partes:
● @ ngrx / store: este es el núcleo que contiene una forma para que podamos mantener el
estado y despachar acciones.
● @ngrx/effects, maneja los efectos secundarios como, por ejemplo, las solicitudes de
AJAX.
● @ ngrx / router-store: Asegura que podamos integrar NgRx con Angular routing.
● @ngrx/store-devtools: Instala una herramienta que nos da la oportunidad de depurar
NgRx, por ejemplo, dándonos un viaje en el tiempo depuración de la funcionalidad.
● @ngrx/entity: esta es una biblioteca que nos ayuda a administrar las colecciones de
registros.
● @ngrx/schematics: esta es una biblioteca de andamios que lo ayuda cuando usa NgRx.
42
3.6 Caso Práctico
El presente ejemplo muestra cómo definir la creación y eliminación de usuarios, haciendo uso
del Redux con Angular.
Pasos:
3.6.1 Instalación
Instalar ngrx/store con el siguiente con el siguiente comando: npm install @ngrx/store.
3.6.2 Creación del Modelo de Datos
export class Customer {

id: string;
name: string;
age: number;
active: boolean;
constructor(id?: string, name?: string, age?: number, active?: boolean) {

this.id = id;
this.name = name;
this.age = age;
this.active = active;
}
}
app/customers/models/customer.ts
3.6.3 Creación de las Acciones
app/actions/customer.actions.ts
import { Injectable } from '@angular/core';

import { Action } from '@ngrx/store';
import { Customer } from '../customers/models/customer';
export const CREATE_CUSTOMER = 'Customer_Create';

export const DELETE_CUSTOMER = 'Customer_Delete';
export class CreateCustomer implements Action {

43
readonly type = CREATE_CUSTOMER;
constructor(public payload: Customer) { }

}
export class DeleteCustomer implements Action {

readonly type = DELETE_CUSTOMER;
constructor(public id: string) { }

}
export type Actions = CreateCustomer | DeleteCustomer;
3.6.4 Creación de los Reductores
app/reducers/customer.reducer.ts
import { Customer } from '../customers/models/customer';

import { Actions, CREATE_CUSTOMER, DELETE_CUSTOMER } from '../actions/customer.actions';
const initialState: Customer = {

id: '1',
name: 'Andrien',
age: 27,
active: true
};
export function reducer(

state: Customer[] = [initialState],
action: Actions) {
switch (action.type) {
case CREATE_CUSTOMER:
return [...state, action.payload];
case DELETE_CUSTOMER:
return state.filter(({ id }) => id !== action.id);
default:
return state;
}
}
44
3.6.5 Creación del App State
app/app.state.ts
import { Customer } from './customers/models/customer';
export interface AppState {

readonly customer: Customer[];
}
3.6.6 Importar el Almacén Ngrx
app/app.module.ts
import { BrowserModule } from '@angular/platform-browser';

import { NgModule } from '@angular/core';
import { StoreModule } from '@ngrx/store';

import { reducer } from './reducers/customer.reducer';
import { AppComponent } from './app.component';

import { CreateCustomerComponent } from './customers/create-customer/create-
customer.component';
import { CustomersListComponent } from './customers/customers-list/customers-list.component';
import { CustomerDetailsComponent } from './customers/customer-details/customer-
details.component';
@NgModule({
declarations: [
AppComponent,
CreateCustomerComponent,
CustomersListComponent,
CustomerDetailsComponent
],
imports: [
BrowserModule,
StoreModule.forRoot({
customer: reducer
})
],
providers: [],
bootstrap: [AppComponent]
})
45
export class AppModule { }
3.6.7 Creación del Componente Customer
customers/create-customer/create-customer.component.ts
import { Component, OnInit } from '@angular/core';

import { Store } from '@ngrx/store';
import { AppState } from '../../app.state';
import { CreateCustomer } from '../../actions/customer.actions';
@Component({
selector: 'app-create-customer',
templateUrl: './create-customer.component.html',
styleUrls: ['./create-customer.component.css']
})
export class CreateCustomerComponent implements OnInit {
constructor(private store: Store<AppState>) { }
ngOnInit() {
}
saveCustomer(id, name, age) {

this.store.dispatch(new CreateCustomer(
{
id: id,
name: name,
age: age,
active: false
}
));
}
}
customers/create-customer/create-customer.component.html
<div style="max-width:300px;">
<h3>Create Customers</h3>
<div class="form-group">
<input class="form-control" type="text" placeholder="id" #id>
</div>
<input class="form-control" type="text" placeholder="name" #name>
46
</div>
<input class="form-control" type="number" placeholder="age" #age>
</div>
<button class="btn btn-success" (click)="saveCustomer(id.value,name.value,age.value)">Save
Customer</button>
</div>
3.6.8 Creación del Componente Customer Details
customers/customer-details/customer-details.component.ts
import { Component, OnInit, Input } from '@angular/core';

import { Customer } from '../models/customer';
import { DeleteCustomer } from '../../actions/customer.actions';
@Component({
selector: 'app-customer-details',
templateUrl: './customer-details.component.html',
styleUrls: ['./customer-details.component.css']
})
export class CustomerDetailsComponent implements OnInit {
@Input() customer: Customer;
constructor(private store: Store<AppState>) { }
ngOnInit() {
}
removeCustomer(id) {
this.store.dispatch(new DeleteCustomer(id));
}
}
customers/customer-details/customer-details.component.html
<div *ngIf="customer">
<div>
<label>Name: </label> {{customer.name}}
</div>
<div>
47
<label>Age: </label> {{customer.age}}

</div>
<span class="button is-small btn-danger" (click)='removeCustomer(customer.id)'>Delete</span>
<hr/>
</div>
3.6.9 Creación del Componente Customer List
customers/customers-list/customers-list.component.ts
import { Component, OnInit } from '@angular/core';

import { Observable } from 'rxjs';
import { Customer } from '../models/customer';

@Component({
selector: 'app-customers-list',
templateUrl: './customers-list.component.html',
styleUrls: ['./customers-list.component.css']
})
export class CustomersListComponent implements OnInit {
customers: Observable<Customer[]>;
constructor(private store: Store<AppState>) {

this.customers = store.select('customer');
}
ngOnInit() {
}
customers/customers-list/customers-list.component.html
<div *ngIf="customers">
<h3>Customers</h3>
<div *ngFor="let customer of customers | async">
<app-customer-details [customer]='customer'></app-customer-details>
</div>
48
</div>
3.6.10 Importación de los Componentes al App Component
app/app.component.ts
import { Component } from '@angular/core';

@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent {
title = 'grokonez';
description = 'NgRx Example';
}
app/app.component.html
<div class="container">
<div style="color: blue;">
<h1>{{title}}</h1>
<h3>{{description}}</h3>
</div>
<div class="row">
<div class="col-sm-4">
<app-create-customer></app-create-customer>
</div>
<div class="col-sm-4">
<app-customers-list></app-customers-list>
</div>
</div>
</div>
49
3.6.11 Vista de Interfaz de Usuario
Figura 10: Interfaz de Usuario Customers usando Ngrx y Angular.

50
CONCLUSIONES
A través de este trabajo de investigación se puede llegar a las siguientes conclusiones:
● Cuando se construyen aplicaciones web empresariales, que tienden a crecer, es
recomendable utilizar una arquitectura por capas con un patrón de arquitectura Flux, ya
que hace más fácil su mantenibilidad.
● Igualmente, usar el patrón Redux permite que la aplicación se comporte de forma
predecible – a pesar de un crecimiento exponencial de flujo de datos - haciendo que
minimice los errores de actualizaciones de estado.
● En cuanto al uso de los módulos de Angular en el desarrollo de aplicaciones web permite
una organización lógica del negocio que se pueden reutilizar y que se pueden comunicar
con diferentes servicios.
● Se pudo ver que el uso del patrón MVVM es bastante útil, ya que se basa en la separación
de las interfaces de usuario. Ayuda a la simplificación de las tareas de desarrollo y
mantenimiento del software escrito a través de la división de capas.
● Al usar la arquitectura Flux, los datos fluyen en una sola dirección permitiendo tener
mayor control de la aplicación y como se dijo anteriormente ayuda a la detección de
errores en la capa de presentación
● Utilizando funciones puras a través de Redux, se obtiene una sustancial mejora, en lugar
de modificar directamente el estado y utilizar las acciones, éstas transforman el estado de
toda la aplicación simultáneamente sin tener que cambiar el estado en cada una de las
vistas, simplificando así el flujo de la aplicación.

51
● El uso de la librería NgRx es útil, al ser una implementación de Redux hecha para
Angular, los conceptos como almacenes, creadores de acciones, acciones, selectores y
reductores son bien utilizados. Se logro la creación de aplicaciones más sólidas
organizando mejor el estado de las mismas.

52
BIBLIOGRAFÍA
Referencias
[1] Bugl, D. (2017). Learning Redux. Packt Publishing Ltd.
[2] Dinkevich, I. G. (2017). The Complete Redux Book. Lean Publishing.
[3] Garofalo, R. (2011). Building Enterprise Applications with Windows Presentation
Foundation and the Model View ViewModel . Microsoft Press.
[4] Marc Garreau, W. F. (2018). Redux in Action. Manning Publications Co.
[5] Noring, C. (2018). Architecting Angular Applications with Redux, RxJS, and NgRx. Packt
Publishing Ltd.
Sitios Web
[6] Angular. (2018, septiembre 29). Angular - Architecture Overview. Retrieved from
https://angular.io/guide/architecture
[7] Microsoft. (2018, Septiembre 29). Retrieved from https://docs.microsoft.com/en-
us/xamarin/xamarin-forms/enterprise-application-patterns/mvvm
[8] Redux. (2018, Septiembre 29). Redux Org. Retrieved from https://redux.js.org/

Diseño de Aplicaciones Web Basadas en Arquitectura de Capas Usando La Librería Redux

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Diseño de Aplicaciones Web Basadas en Arquitectura de Capas Usando La Librería Redux

Enviado por

Direitos autorais:

Formatos disponíveis

Universidad Mayor de “San Simón”

Facultad de Ciencias y Tecnología

Diseño de Aplicaciones Web basadas en Arquitectura de

Capas usando la Librería Redux

Carrera: Ingeniería de Sistemas

Tutor: Ing. Edson Ariel Terceros Torrico

Fecha: Septiembre de 2018

A mi madre y a mi hijo, con mucho

amor y cariño les dedico todo mi

esfuerzo y trabajo puesto para la

realización de esta monografía

A Dios porque está conmigo en cada paso que

A mi madre, quien a lo largo de mi vida ha

A Mi hijo, por ser mi motor de continua

A mi hermana, por su apoyo incondicional que

A mis hermanos, por sus consejos y

A Sigrid, por su confianza para lograr un

A Claudia Ossio, por su constante apoyo en el

Al Ing. Edson Terceros, por su paciencia y

A mis amigos, por sus enseñanzas y consejos

1.1 Antecedentes Generales.............................................................................................. 12

1.2 Antecedentes Específicos ........................................................................................... 13

3.1 Angular (Capas, Servicios y Componentes ................................................................ 14

3.1.2 Componentes ........................................................................................................... 17

3.1.3 Plantillas, directivas y enlace de datos................................................................... 17

3.1.4 Servicios e inyección de dependencia ..................................................................... 18

3.2 Modelo Vista Vista Modelo (MVVM) ............................................................................. 20

3.2.1 Modelo .................................................................................................................... 22

3.2.2 Vista ........................................................................................................................ 23

3.2.3 Vista Modelo ........................................................................................................... 24

3.3 Flux ................................................................................................................................... 25

3.3.1 Vista ........................................................................................................................ 27

3.3.3 Acciones .................................................................................................................. 27

3.3.4 Despachador ........................................................................................................... 28

3.3.5 Implementaciones de Flux ...................................................................................... 29

3.4 Redux ................................................................................................................................ 29

3.4.1 Arquitectura Redux y sus Principales Características ........................................... 32

3.4.2 Principios de Redux ................................................................................................ 37

3.5 NgRx ................................................................................................................................. 40

3.6 Caso Práctico .................................................................................................................... 42

3.6.2 Creación del Modelo de Datos ............................................................................... 42

3.6.3 Creación de las Acciones ........................................................................................ 42

3.6.4 Creación de los Reductores .................................................................................... 43

3.6.5 Creación del App State ........................................................................................... 44

3.6.6 Importar el Almacén Ngrx ...................................................................................... 44

3.6.7 Creación del Componente Customer ...................................................................... 45

3.6.8 Creación del Componente Customer Details ......................................................... 46

3.6.9 Creación del Componente Customer List ............................................................... 47

3.6.10 Importación de los Componentes al App Component............................................. 48

3.6.11 Vista de Interfaz de Usuario ................................................................................... 49

TABLA DE CUADROS, GRAFICOS Y FIGURAS

Figura 1: Descripción de la arquitectura MVVM. ........................................................................ 22

Figura 2: Arquitectura del Patrón Flux. ........................................................................................ 26

Figura 3: Comparativa de Componentes con y sin Redux. ........................................................... 32

Figura 4: Patrón Redux y sus componentes. ................................................................................. 33

Figura 5: Ejemplo de Objeto de Acción. ...................................................................................... 34

Figura 6: Ejemplo de una función que crea un objeto de Acción. ................................................ 34

Figura 7: Implementación simple de un Reductor. ....................................................................... 36

Figura 8: Visualización del código de un despachador. ............................................................... 38

Figura 9: Declaración de cambios con funciones puras................................................................ 39

Figura 10: Interfaz de Usuario Customers usando Ngrx y Angular. ............................................ 49

problemas, es el flujo de datos bidireccional, donde un cambio en la interfaz dispara múltiples

depurar y resolver un problema.

El resultado de la presente monografía ayudará a la implementación y el uso del patrón Redux de