Cómo crear un Store o State Management con RxJS en Angular (Parte 1/2)

Mayra Rodriguez
5 min readJan 21, 2020

--

Abstract — La programación reactiva es uno de los paradigmas más interesantes hoy en día que nos permite solucionar de una manera más eficientes problemas específicos que podemos encontrar en nuestras aplicaciones. No solo propone una solución basada en el patrón del Observer y el Iterator, si no que también se enfoca en la propagación de cambios en nuestra aplicación, es allí de donde nace el State Management, una implementación que nos ayuda no sólo mejorando la experiencia del usuario en nuestras aplicaciones, si no también manejando el estado de un objeto o una variable y a su vez podamos “escuchar” cualquier cambio que pueda tener a través de toda nuestra aplicación.

Foto del día del Evento de la JSConf en Colombia

Primero lo primero

Antes de comenzar hablar un poco sobre el Store, es importante tomar en cuenta que debes tener conocimientos básicos sobre:

Ahora sí,

¿Qué es un store?

Un store viene siendo una especie de almacenamiento local en nuestra aplicación web (puede usarse en una API o en una app frontend dependiendo de los requerimientos que se tengan). Puede verse como una base de datos por que podemos hacer creaciones, actualizaciones, eliminaciones o inclusive cualquier lógica que queramos aplicarle, pero es muy importante que tengamos en cuenta que: trabajaremos con inmutabilidad, además el almacenamiento será en memoria, esto significa que será volátil y que se puede borrar fácilmente al hacer un refresh de nuestra página, por lo que no almacenaremos nada en localStorage, indexedDB o cualquier otro tipo de almacenamiento no volátil.

¿Para qué nos sirve un store?

La principal funcionalidad que podemos apreciar del store es el mejoramiento del performance en nuestras aplicaciones, ya que en muchos casos podemos trabajar con la data almacenada localmente sin esperar a una respuesta del backend o de la petición http al momento de enviar información, actualizarla y demás. Es decir, básicamente trabajaríamos con la data que tenemos localmente y luego le enviamos los cambios al backend, lo cual puede ser algo completamente asíncrono en nuestra aplicación que casi el usuario ni lo note.

Además, aunque podamos implementarlo en uno o más servicios, un Store nos puede proveer mucho más que eso, como mantenibilidad del código, escalabilidad a la ahora de agregar nuevos features, mejor debugger, entre otros.

Y adicionalmente, aunque no lo abarcaremos en este post, podemos devolvernos a estados anteriores luego de un determinado proceso como por ejemplo una petición http fallida. Un ejemplo de esto lo implementa Google Drive, cuando intentamos eliminar un archivo, y de repente no tenemos internet o tenemos errores de conexión, aunque él nos muestra como si se hubiera eliminado el archivo, luego de que hace la petición y esta falla, en la vista aparece nuevamente el archivo que pensamos haber eliminado (se devuelve al estado anterior) y nos aparece una notificación diciendo que falló nuestra solicitud, es decir, inicialmente nos dio la sensación de que sí lo eliminó, pero luego nos notificó que no se realizó bien el proceso (lo cual se conoce como Enfoque Optimista), esto ayuda mucho a la experiencia del usuario debido a que tendrá la sensación de que aplicación está corriendo, funcionando y su interacción no quedó “en visto” por así decirlo.

Conceptos Fundamentales

Ahora bien es importante conocer los conceptos importantes antes de empezar:

Observables

No olvidemos que los observables representan un conjunto de datos que se esperan recibir en un determinado momento, este conjunto de datos puede representarse como un streaming de datos, así mismo está muy relacionado a la propagación de eventos (lo cual veremos más adelante en el demo), .

Si necesitas un poco más de introducción a los Observables puedes leer un post que escribí recientemente https://medium.com/@mayrarodriguez/conozcamos-los-observables-15ee9e7c5aa9 ya que les dará una pequeña introducción acerca de como funcionan los observables y como es su comportamiento.

Streaming de Gatos

Subject

El Subject tiene un comportamiento similar al Observable, con la diferencia principal de que soporta Multicast,

¿qué significa esto? Veamos un ejemplo.

Si creamos un observable que emite de manera random un número y nos suscribimos multiples veces a este observable, en cada suscripción nos emitirá un valor distinto.

Ejemplo de un Observable emitiendo números random y sus tres suscripciones

Sin embargo si tenemos un subject con la misma lógica de emitir números randoms, en cada suscripción que le hagamos tendremos el mismo valor.

Ejemplo de un Subject emitiendo números random y sus tres suscripciones

Esto es muy importante cuando queremos trabajar con un Store o Stage Management ya que nos interesa que este Store sea una única fuente de la verdad, es decir, que desde cualquier lugar que consultemos su información, nos devuelva siempre el mismo estado o valor y no uno distinto, con la finalidad de evitar errores en nuestro código.

Behavior Subject

Ahora bien, dentro de los tipos de subject podemos encontrar el ReplaySubject, BehaviorSubjecty el AsyncSubject, pero en este post escribiré sobre el BehaviorSubject particularmente, ya que tiene un comportamiento importante necesario para nuestro store.

Pero ¿cómo funciona?

El Behavior Subject posee un almacenamiento en memoria del último estado que recibió, lo cual significa que al momento de suscribirnos al store, aunque este no haya recibido un push o un dispatch aún, podemos recibir el último estado que tiene el store, así mismo, si no ha recibido un update en alguna interacción del usuario, podemos nosotros configurarle un estado inicial.

En el caso del subject no posee un almacenamiento en memoria del último estado que recibió y por ello al momento de suscribirnos a él no sabemos que pasó antes, no sabemos que datos recibió antes y esto puede resultar un poco complejo cuando tenemos el store. Adicionalmente, usando el subject no podríamos saber el estado actual del store, solo podríamos saberlo luego de que este reciba un update o un push el cual se da en el subject cuando recibe el .next (el cual permite emitir o hacer dispatch de un nuevo valor) y este debe darse luego de la suscripción al mismo.

Veamos este ejemplo del subject:

Ejemplo de un Subject en RxJS

Si pueden notarlo, existe dos mensajes en este ejemplo, el primero dice:"Esto no se va a mostrar :(" y luego vemos otro que dice Pero esto sí! .

Ahora veamos el ejemplo del BehaviorSubject

Ejemplo de un BehaviorSubject en RxJS

Pero bueno, sin más preámbulos, comencemos a codear!

Para continuar con la siguiente parte, puedes hacer click aquí.

--

--

Mayra Rodriguez

Google Developer Expert for Angular — Senior FullStack Engineer at Terminal Labs