Introducción
Este es el primero de una serie de artículos sobre la creación de aplicaciones reactivas en Angular utilizando la gestión de estados con NgRx. Quiero comenzar exponiendo mi relación personal con NgRx e introducir una aplicación de ejemplo que usaremos a lo largo de la serie.
Deberías estar ya familiarizado con los conceptos comunes de NgRx para sacar el máximo provecho de estos artículos. En artículos posteriores, compartiré las cosas buenas y malas que he aprendido sobre la gestión de estados e ilustraré las mejores prácticas para NgRx.
Si tu quieres leer más contenido acerca de Angular te invito a visitar mi blog
El repositorio de GitHub está disponible en: https://github.com/rainerhahnekamp/ngrx-best-practices
Traducción en español del artículo original de Rainer Hahnekamp "NgRx Best Practices Series: 0. Introduction" publicado el 15 enero 2021
Una Solución para La Gestión de Estado
Desde el año 2000, he estado trabajando con aplicaciones de JavaScript de gran tamaño. Antes de que preguntes, en el año 2000 lo llamábamos DHTML y todo lo que tenías era Visual InterDev. No existía un framework de JavaScript. Siempre traté usar los frameworks de vanguardia de esa época: Dojo, ExtJs, AngularJS.
Siempre sentí que algo estaba mal en la forma de tratar los datos, especialmente cuando los datos se empleaban en varios lugares y se producía un cambio en uno de ellos. ¿Cómo mantener los datos sincronizados?
Se me ocurrieron funciones que notificaban a las partes relevantes, recargaba toda la página después de una actualización de la base de datos y hacía cosas aún más feas que ya no puedo ni quiero recordar.
No es de extrañar que me entusiasmara inmediatamente cuando oí hablar de la arquitectura Flux y de que era la solución para ese problema concreto. También tenía un nombre bastante pegadizo: State Management.
Han pasado tres años desde entonces. ¿Y qué puedo decir? No me ha decepcionado en absoluto.
¿Por qué hay que utilizar un State Management?
Mucha gente se pregunta si la gestión de estados es o no excesiva en una aplicación. Yo tengo una opinión clara al respecto: No. En cuanto tengamos varios componentes que se ocupen del mismo estado, debemos usar un State Management.
Puede que algunos proyectos no lo necesiten, pero los veo como una minoría. En mi experiencia, la necesidad de la gestión de estados se produce muy rápidamente.
Cuando se trata de codificar la gestión de estados, me gusta NgRx. Mejora la estructura de mis aplicaciones. Cada elemento tiene su responsabilidad y su lugar. Esto me permite orientarme rápidamente. Y no sólo a mí. Lo mismo se aplica a los nuevos desarrolladores. Siempre que conozcan NgRx, podrán ser productivos muy rápidamente. Por último, pero no menos importante, no vuelvo a cometer los mismos errores. NgRx proporciona las mejores prácticas. Puedo confiar con seguridad en su experiencia incorporada.
Al decir que NgRx añadiría beneficios para la mayoría de las aplicaciones, no quiero decir que debamos poner la gestión de estados en cada rincón de nuestra aplicación. Cuando tenemos un estado que sólo se aplica a un solo componente, no deberíamos usar NgRx. Sin embargo, hay excepciones a esta regla, pero serán tratadas en un próximo artículo.
¿Cuál es el problema entonces? Tenemos que ser conscientes de que la gestión de estados añade un montón de código repetitivo a nuestra base de código. Eso no debería asustarnos. A medida que la base de código general crezca, los beneficios superarán rápidamente los costes.
Debido al estricto enfoque y diseño de NgRx, se siente un poco inflexible y torpe en algunos casos de uso. Pero podemos superar esto. Podemos apoyarnos en las mejores prácticas. Algunas son parte de esta serie. Por eso es probable que sigas leyendo, ¿no?
Demostración de las mejores prácticas de NgRx
Para simplificar, tenemos una simple aplicación CRUD para una entidad Customer. Mostramos una lista de entradas de Customer y proporcionamos un formulario para añadir o editar dicho cliente. La entrada en sí es de tipo Customer tiene la siguiente interfaz.
export interface Customer {
id: number;
firstname: string;
name: string;
country: string;
birthdate: string;
}
En NgRx, tenemos acciones para cargar, actualizar, añadir y eliminar. Como se requiere la comunicación con el backend vienen en los pares habituales, como "load"/"loaded". Los efectos manejan la comunicación con el backend y también tenemos selectores.
export const customerFeatureKey = 'Customer';
export interface State {customers: Customer[]}
export interface CustomerAppState {
[customerFeatureKey]: State;
}
export const initialState: State = {customers: []};
export const customerReducer = createReducer<State>(
initialState,
on(CustomerActions.loaded, (state, { customers }) => ({...state, customers})),
on(CustomerActions.added, (state, { customers }) => ({...state, customers})),
on(CustomerActions.updated, (state, { customers }) => ({...state, customers})),
on(CustomerActions.removed, (state, { customers }) => ({...state, customers}))
);
Solamente se requieren dos componentes. Un componente lista los clientes y el componente de detalle proporciona la funcionalidad de añadir o editar una entrada. El formulario de detalle también contiene un botón para borrar.
Antes de empezar...
Independientemente de lo que pienses cuando empieces a utilizar la gestión de estados, pronto te tropezarás con algunos casos de uso en los que la documentación oficial te deja en tierra de nadie. Espero que la recopilación de buenas prácticas de esta serie te ayude un poco.
Si ya es un usuario experimentado de NgRx, espero que haya una o dos cosas que pueda llevarse. Incluso si usted es un veterano y dice "no había nada nuevo para mí", entonces estaría encantado de escuchar sus comentarios o tal vez una mejor práctica o patrón que usted encuentra que falta en mi lista.