DEV Community: ng-content

Construyendo un Workflow Designer basado en plugins con Angular y Module Federation

ng-content — Wed, 27 Jul 2022 05:12:00 +0000

En el artículo anterior de esta serie, mostré cómo utilizar Dynamic Module Federation. Esto nos permite cargar Microfrontends - o remotos, que es el término más general en Module Federation - no conocidos en tiempo de compilación. Ni siquiera necesitamos saber el número de Microfrontends por adelantado.

Mientras que el artículo anterior aprovechaba el router para integrar los Microfrontends o remotes disponibles, este artículo muestra cómo cargar componentes individuales. El ejemplo utilizado para esto es un simple diseñador de workflow basado en plugins.

Traducción en español del artículo original de Manfred Steyer "Building A Plugin-based Workflow Designer With Angular and Module Federation" actualizado el 10-06-2021

El diseñador de workflow actúa como un llamado host que carga las tareas de los plugins proporcionados como remotes. Así, pueden ser compilados y desplegados individualmente. Después de iniciar el workflow designer este obtiene una configuración que describe los plugins disponibles:

Tenga en cuenta que estos plugins se proporcionan a través de diferentes orígenes (http://localhost:4201 y http://localhost:4202), y el diseñador de flujo de trabajo se sirve de un origen propio (http://localhost:4200).

📂 Código fuente

Gracias a Zack Jackson y Jack Herrington, que me ayudaron a entender el rater nuevo API para la Federación de Módulos Dinámicos.

Importante: Este artículo está escrito para Angular y Angular CLI 14.x y superior. Asegúrate de que tienes una versión adecuada si pruebas los ejemplos que aquí se describen.

Construyendo los plugins

Los plugins se proporcionan a través de aplicaciones Angular separadas. Para simplificar, todas las aplicaciones son parte del mismo monorepo. Su configuración de webpack utiliza Module Federation para exponer los plugins individuales como se muestra en los artículos anteriores de esta serie:

const { shareAll, withModuleFederationPlugin } = require('@angular-architects/module-federation/webpack');

 module.exports = withModuleFederationPlugin({

   name: 'mfe1',

   exposes: {
     './Download': './projects/mfe1/src/app/download.component.ts',
     './Upload': './projects/mfe1/src/app/upload.component.ts'
   },

   shared: {
     ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
   },

 });

Una diferencia con las configuraciones mostradas en los artículos anteriores es que aquí estamos exponiendo directamente componentes independientes. Cada componente representa una tarea que puede ser puesta en el flujo de trabajo.

La combinación de singleton: true y strictVersion: true hace que webpack emita un error en tiempo de ejecución cuando el shell y el/los micro frontend(s) necesitan diferentes versiones incompatibles (por ejemplo, dos versiones mayores diferentes). Si omitiéramos strictVersion o lo pusiéramos en falso, webpack solamente emitiría una advertencia en tiempo de ejecución.

Cargar los Plugins en el Workflow Designer

Para cargar los plugins en el workflow designer, estoy utilizando la función de ayuda loadRemoteModule proporcionada por el plugin @angular-architects/module-federation. Para cargar usamos loadRemoteModule de esta manera

import { loadRemoteModule } from '@angular-architects/module-federation';

 [...]

 const component = await loadRemoteModule({
     type: 'module',
     remoteEntry: 'http://localhost:4201/remoteEntry.js',
     exposedModule: './Download'
 })

Proporcionar metadatos sobre los plugins

En tiempo de ejecución, necesitamos proporcionar al Workflow Designer los datos clave sobre los plugins. El tipo utilizado para esto se llama PluginOptions y extiende el LoadRemoteModuleOptions mostrado en la sección anterior por un displayName y un componentName:

export type PluginOptions = LoadRemoteModuleOptions & {
     displayName: string;
     componentName: string;
 };

Una alternativa a esto es extender el Manifiesto de la Module Federation como se muestra en el artículo anterior sobre Module Federation Dinamico.

Mientras que el displayName es el nombre que se presenta al usuario, el componentName se refiere a la clase TypeScript que representa el componente Angular en cuestión.

Para cargar estos datos clave, el workflow designer aprovecha un LookupService:

@Injectable({ providedIn: 'root' })
 export class LookupService {
     lookup(): Promise<PluginOptions[]> {
         return Promise.resolve([
             {
                 type: 'module',
                 remoteEntry: 'http://localhost:4201/remoteEntry.js',
                 exposedModule: './Download',

                 displayName: 'Download',
                 componentName: 'DownloadComponent'
             },
             [...]
         ] as PluginOptions[]);
     }
 }

En aras de la simplicidad, el LookupService proporciona algunas ya entradas definidas, pero en el mundo real, es muy probable que solicite estos datos desde un punto final HTTP respectivo.

Creando Dinámicamente el Componente del Plugin

El Workflow Designer representa los plugins con un PluginProxyComponent. Toma un objeto PluginOptions a través de una entrada, carga el plugin descrito a través de Module Federation Dinámico y muestra el componente del plugin en el placeHolder:

@Component({
     standalone: true,
     selector: 'plugin-proxy',
     template: `
         <ng-container #placeHolder></ng-container>
     `
 })
 export class PluginProxyComponent implements OnChanges {
     @ViewChild('placeHolder', { read: ViewContainerRef, static: true })
     viewContainer: ViewContainerRef;

     constructor() { }

     @Input() options: PluginOptions;

     async ngOnChanges() {
         this.viewContainer.clear();

         const Component = await loadRemoteModule(this.options)
             .then(m => m[this.options.componentName]);

         this.viewContainer.createComponent(Component);
     }
 }

En versiones anteriores a Angular 13, necesitábamos utilizar un ComponentFactoryResolver para obtener la fábrica del componente cargado:

// Before Angular 13, we needed to retrieve a ComponentFactory
 //
 // export class PluginProxyComponent implements OnChanges {
 //     @ViewChild('placeHolder', { read: ViewContainerRef, static: true })
 //     viewContainer: ViewContainerRef;

 //     constructor(
 //       private injector: Injector,
 //       private cfr: ComponentFactoryResolver) { }

 //     @Input() options: PluginOptions;

 //     async ngOnChanges() {
 //         this.viewContainer.clear();

 //         const component = await loadRemoteModule(this.options)
 //             .then(m => m[this.options.componentName]);

 //         const factory = this.cfr.resolveComponentFactory(component);

 //         this.viewContainer.createComponent(factory, null, this.injector);
 //     }
 // }

Conectando Todo

Ahora, es el momento de conectar las partes mencionadas anteriormente. Para ello, el AppComponent del workflow designer obtiene un array de plugins y de workflows. El primero representa las PluginOptions de los plugins disponibles y, por lo tanto, todas las tareas disponibles, mientras que el segundo describe las PluginOptions de las tareas seleccionadas en la configuracion:

@Component({ [...] })
 export class AppComponent implements OnInit {

   plugins: PluginOptions[] = [];
   workflow: PluginOptions[] = [];
   showConfig = false;

   constructor(
     private lookupService: LookupService) {
   }

   async ngOnInit(): Promise<void> {
     this.plugins = await this.lookupService.lookup();
   }

   add(plugin: PluginOptions): void {
     this.workflow.push(plugin);
   }

   toggle(): void {
     this.showConfig = !this.showConfig;
   }
 }

El AppComponent utiliza el LookupService inyectado para rellenar su array de plugins. Cuando se añade un plugin al workflow, el método add pone su objeto PluginOptions en la array del workflow.

Para mostrar el workflow, el diseñador simplemente itera todos los elementos en la array del workflow y crea un plugin-proxy para ellos:

<ng-container *ngFor="let p of workflow; let last = last">
     <plugin-proxy [options]="p"></plugin-proxy>
     <i *ngIf="!last" class="arrow right" style=""></i>
 </ng-container>

Como se ha comentado anteriormente, el proxy carga el plugin (al menos, si no está ya cargado) y lo muestra.

Además, para renderizar el menu de tasks que se muestra a la izquierda, recorre todas las entradas del array de plugins. Para cada uno de ellos muestra un hipervínculo que llama al método add:

<div class="vertical-menu">
     <a href="#" class="active">Tasks</a>
     <a *ngFor="let p of plugins" (click)="add(p)">Add {{p.displayName}}</a>
 </div>

Conclusión

Si bien Module Federation es útil para implementar Micro Frontends, también puede utilizarse para establecer arquitecturas de complementos. Esto nos permite extender una solución existente por parte de terceros. También parece ser un buen ajuste para las aplicaciones SaaS, que necesitan ser adaptadas a las necesidades de diferentes clientes.

Module Federation Dinámico con Angular

ng-content — Wed, 27 Jul 2022 05:10:00 +0000

Traducción en español del artículo original de Manfred Steyer "Dynamic Module Federation with Angular" actualizado el 09-06-2022

En el artículo anterior de esta serie, he mostrado cómo utilizar Webpack Module Federation para cargar Micro frontends compilados por separado en un shell. Como la configuración de webpack del shell describe los Micro Frontendsya definidos.

En este artículo, estoy asumiendo una situación más dinámica donde el shell no conoce el Micro Frontend por adelantado. En su lugar, esta información se proporciona en tiempo de ejecución a través de un archivo de configuración. Mientras que este archivo es un archivo JSON estático en los ejemplos mostrados aquí, su contenido también podría venir de una API Web.

Importante: Este artículo está escrito para Angular y Angular CLI 14 o superior.

La siguiente imagen muestra la idea descrita en este artículo:

Este es el ejemplo de configuracion de los Micro Frontends de los que el shell necesita encontrar en tiempo de ejecución, estos se estan mostrado en el menú y al hacer clic en él, este es cargado y mostrado por el router del la shell.

📂 Código fuente (versión simple, branch: simple)

📂 Código fuente (versión completa)

Dinamico y simple

Vamos a empezar con un enfoque simple. Para esto, asumimos que conocemos los Micro Frontends por adelantado y solamente queremos cambiar sus URLs en tiempo de ejecución, por ejemplo, con respecto al entorno actual. Un enfoque más avanzado, en el que ni siquiera necesitamos conocer el número de Micro Frontends por adelantado, se presenta a continuación.

Agregando Modulo Federation

El proyecto de demostración que utilizamos contiene un shell y dos Micro Frontends llamados mfe1 y mfe2. Como en el artículo anterior, añadimos e inicializamos el plugin Module Federation para los Micro Frontends:



npm i -g @angular-architects/module-federation -D

ng g @angular-architects/module-federation --project mfe1 --port 4201 --type remote

ng g @angular-architects/module-federation --project mfe2 --port 4202 --type remote

Generación de un Manifiesto

A partir de la versión 14.3 del plugin, podemos generar un host dinámico que toma los datos escenciales sobre los Micro Frontend de un archivo json.



ng g @angular-architects/module-federation --project shell --port 4200 --type dynamic-host

Esto genera una configuración de webpack, el manifiesto y agrega código en el main.ts para cargar el manifiesto que se encuentra projects/shell/src/assets/mf.manifest.json.

El manifiesto contiene la siguiente definicion:



{
    "mfe1": "http://localhost:4201/remoteEntry.js",
    "mfe2": "http://localhost:4202/remoteEntry.js"
}

Es importante, después de generar el manifiesto, asegúrarnos que los puertos coinciden.

Cargando el manifiesto

El archivo main.ts generado carga el manifiesto:



import { loadManifest } from '@angular-architects/module-federation';

loadManifest("/assets/mf.manifest.json")
  .catch(err => console.error(err))
  .then(_ => import('./bootstrap'))
  .catch(err => console.error(err));

Por defecto, loadManifest no sólo carga el manifiesto sino también las entradas remotas a las que apunta el manifiesto. Por lo tanto, Module Federation obtiene todos los metadatos necesarios para obtener los Micro Frontends bajo demanda.

Carga de los Micro Frontends

Para cargar los Micro Frontends descritos por el manifiesto, utilizamos las siguientes rutas:



export const APP_ROUTES: Routes = [
    {
      path: '',
      component: HomeComponent,
      pathMatch: 'full'
    },
    {
      path: 'flights',
      loadChildren: () => loadRemoteModule({
          type: 'manifest',
          remoteName: 'mfe1',
          exposedModule: './Module'
        })
        .then(m => m.FlightsModule)
    },
    {
      path: 'bookings',
      loadChildren: () => loadRemoteModule({
          type: 'manifest',
          remoteName: 'mfe2',
          exposedModule: './Module'
        })
        .then(m => m.BookingsModule)
    },
];

La opción type: 'manifest' hace que loadRemoteModule busque los datos clave necesarios en el manifiesto cargado y la propiedad remoteName apunta a la clave que se utilizó en el manifiesto.

Configuración de los Micro Frontends

Esperamos que ambos Micro Frontends proporcionen un NgModule con sub-rutas a través de './Module'. Los NgModules se exponen a través del webpack.config.js en los Micro Frontends:



// projects/mfe1/webpack.config.js

const { shareAll, withModuleFederationPlugin } = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({

  name: 'mfe1',

  exposes: {
    // Adjusted line:
    './Module': './projects/mfe1/src/app/flights/flights.module.ts'
  },

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },

});



// projects/mfe2/webpack.config.js

const { shareAll, withModuleFederationPlugin } = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({

  name: 'mfe2',

  exposes: {
    // Adjusted line:
    './Module': './projects/mfe2/src/app/bookings/bookings.module.ts'
  },

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },

});

Creando la navegacion

Para cada ruta que carga un Micro Frontend, el AppComponent del shell contiene un routerLink:



<!-- projects/shell/src/app/app.component.html -->
<ul>
    <li><img src="../assets/angular.png" width="50"></li>
    <li><a routerLink="/">Home</a></li>
    <li><a routerLink="/flights">Flights</a></li>
    <li><a routerLink="/bookings">Bookings</a></li>
</ul>

<router-outlet></router-outlet>

Eso es todo. Simplemente inicie los tres proyectos (por ejemplo, utilizando npm run run:all). La principal diferencia con el resultado del artículo anterior es que ahora el shell se informa a sí mismo sobre los Micro Frontends en tiempo de ejecución. Si quieres apuntar el shell a diferentes Micro Frontends, sólo tienes que ajustar el manifiesto.

Configurando las rutas Dinamicas

La solución que tenemos hasta ahora es adecuada en muchas situaciones: El uso del manifiesto permite ajustarlo a diferentes entornos sin reconstruir la aplicación. Además, si cambiamos el manifiesto por un servicio REST dinámico, podríamos implementar estrategias como el A/B testing.

Sin embargo, en algunas situaciones es posible que ni siquiera se conozca el número de Micro Frontends por adelantado. Esto es lo que discutimos aquí.

Añadiendo Metadatos Personalizados al Manifiesto

Para configurar dinámicamente las rutas, necesitamos algunos metadatos adicionales. Para ello, es posible que desee ampliar el manifiesto:



{
    "mfe1": {
        "remoteEntry": "http://localhost:4201/remoteEntry.js",

        "exposedModule": "./Module",
        "displayName": "Flights",
        "routePath": "flights",
        "ngModuleName": "FlightsModule"
    },
    "mfe2": {
        "remoteEntry": "http://localhost:4202/remoteEntry.js",

        "exposedModule": "./Module",
        "displayName": "Bookings",
        "routePath": "bookings",
        "ngModuleName": "BookingsModule"
    }
}

Además de remoteEntry, todas las demás propiedades son personalizadas.

Tipos para la Configuración Extendida

Para representar nuestra configuración extendida, necesitamos algunos tipos que usaremos en la shell:



// projects/shell/src/app/utils/config.ts

import { Manifest, RemoteConfig } from "@angular-architects/module-federation";

export type CustomRemoteConfig = RemoteConfig & {
    exposedModule: string;
    displayName: string;
    routePath: string;
    ngModuleName: string;
};

export type CustomManifest = Manifest<CustomRemoteConfig>;

El tipo CustomRemoteConfig representa las entradas del manifiesto y el tipo CustomManifest el manifiesto completo.

Creación dinámica de rutas

Ahora, necesitamos una función que itere a través de todo el manifiesto y cree una ruta para cada Micro Frontend descrito allí:



// projects/shell/src/app/utils/routes.ts

import { loadRemoteModule } from '@angular-architects/module-federation';
import { Routes } from '@angular/router';
import { APP_ROUTES } from '../app.routes';
import { CustomManifest } from './config';

export function buildRoutes(options: CustomManifest): Routes {

    const lazyRoutes: Routes = Object.keys(options).map(key => {
        const entry = options[key];
        return {
            path: entry.routePath,
            loadChildren: () => 
                loadRemoteModule({
                    type: 'manifest',
                    remoteName: key,
                    exposedModule: entry.exposedModule
                })
                .then(m => m[entry.ngModuleName])
        }
    });

    return [...APP_ROUTES, ...lazyRoutes];
}

Esto nos da la misma estructura, que configuramos directamente arriba.

La shell AppComponent se encarga de unir todo:



@Component({
  selector: 'app-root',
  templateUrl: './app.component.html'
})
export class AppComponent implements OnInit  {

  remotes: CustomRemoteConfig[] = [];

  constructor(
    private router: Router) {
  }

  async ngOnInit(): Promise<void> {
    const manifest = getManifest<CustomManifest>();

    // Hint: Move this to an APP_INITIALIZER 
    //  to avoid issues with deep linking
    const routes = buildRoutes(manifest);
    this.router.resetConfig(routes);

    this.remotes = Object.values(manifest);
  }
}

El método ngOnInit accede al manifiesto cargado (todavía está cargado en el main.ts como se muestra arriba) y lo pasa a la funcion buildRoutes. Las rutas dinámicas recuperadas se pasan al router y los valores de los pares clave/valor en el manifiesto, se ponen en el campo remotesm, estos se utilizan en el template para crear dinámicamente los elementos del menú:



<!-- projects/shell/src/app/app.component.html -->

<ul>
    <li><img src="../assets/angular.png" width="50"></li>
    <li><a routerLink="/">Home</a></li>

    <!-- Dynamically create menu items for all Micro Frontends -->
    <li *ngFor="let remote of remotes"><a [routerLink]="remote.routePath">{{remote.displayName}}</a></li>

    <li><a routerLink="/config">Config</a></li>
</ul>

<router-outlet></router-outlet>

Ahora, probemos esta solución "dinámica" iniciando el shell y los Micro Frontends (por ejemplo, con npm run run:all).

Algunos detalles más

Hasta ahora, hemos utilizado las funciones de alto nivel proporcionadas por el plugin. Sin embargo, para los casos en los que necesites más control, también hay algunas alternativas de bajo nivel:

loadManifest(...): La función loadManifest utilizada anteriormente proporciona un segundo parámetro llamado skipRemoteEntries. Asignarlo a true evita la carga de los puntos de entrada. En este caso, sólo se carga el manifiesto:



loadManifest("/assets/mf.manifest.json", true)
    .catch(...)
    .then(...)
    .catch(...)

setManifest(...): Esta función permite establecer directamente el manifiesto. Es muy útil si se cargan los datos desde otro lugar.

loadRemoteEntry(...): Esta función permite cargar directamente el punto de entrada remoto. Es útil si no se utiliza el manifiesto:



Promise.all([
    loadRemoteEntry({ type: 'module', remoteEntry: 'http://localhost:4201/remoteEntry.js' }),
    loadRemoteEntry({ type: 'module', remoteEntry: 'http://localhost:4202/remoteEntry.js' })
])
.catch(err => console.error(err))
.then(_ => import('./bootstrap'))
.catch(err => console.error(err));

LoadRemoteModule(...): Si no quieres usar el manifiesto, puedes cargar directamente un Micro Frontend con loadRemoteModule:



{
    path: 'flights',
    loadChildren: () =>
        loadRemoteModule({
            type: 'module',
            remoteEntry: 'http://localhost:4201/remoteEntry.js',
            exposedModule: './Module',
        }).then((m) => m.FlightsModule),
},

En general, creo que la mayoría de la gente utilizará el manifiesto en el futuro. Incluso si uno no quiere cargarlo desde un archivo JSON con loadManifest, puede definirlo mediante setManifest.

La propiedad type:'module' define que se quiere cargar un módulo EcmaScript "real" en lugar de "sólo" un archivo JavaScript. Esto es necesario desde Angular CLI 13. Si cargas cosas no construidas es muy probable que tengas que establecer esta propiedad como script. Esto también puede ocurrir a través del manifiesto:



{
    "non-cli-13-stuff": {
        "type": "script",
        "remoteEntry": "http://localhost:4201/remoteEntry.js"
    }
}

Si una entrada del manifiesto no contiene una propiedad de type, el plugin asume el valor module.

Conclusión

Usar Module Federation dinamicos proporciona más flexibilidad ya que permite cargar Micro Frontends que no tenemos que conocer en tiempo de compilación. Ni siquiera tenemos que conocer su número por adelantado. Esto es posible gracias a la API en tiempo de ejecución proporcionada por webpack. Para hacer su uso un poco más fácil, el plugin @angular-architects/module-federation lo envuelve muy bien para simplificanos el trabajo.

Photo by Polina Sushko on Unsplash

La Revolución de Micro Frontend: Module Federation con Angular

ng-content — Wed, 27 Jul 2022 05:07:24 +0000

Traducción en español del artículo original de Manfred Steyer "The Microfrontend Revolution: Module Federation with Angular" actualizado el 06-06-2022

Importante: Este artículo está escrito usando Angular y Angular CLI 14.

En el artículo anterior, he mostrado cómo usar Module Federation, este es parte de webpack a partir de la versión 5, para implementar micro frontends. Este artículo muestra cómo crear un micro frontend basado en Angular utilizando el router para cargar un micro frontend compilado y desplegado por separado.

El resultado es similar al del artículo anterior, pero usando Angular:

El Micro frontend cargado se muestra dentro del borde discontinuo rojo sin la shell:

Puede descargar el codigo desde Github

Usando Module Federation en proyectos de Angular

Nuestro ejemplo aquí asume que tanto el shell como el micro frontend son proyectos en el mismo espacio de trabajo de Angular. Para empezar, necesitamos decirle a la CLI que use Module Federation al momento de generarlos. Sin embargo, como la CLI nos simplifica la configuracion de webpack, nosotros necesitamos hacer en webpack de forma personalizada.

Para eso el paquete @angular-architects/module-federation proporciona esa interfaz media para interactuar y modificar el mismo. Para empezar, utilizarlo y agregarlo en el proyecto, podemos usar el comando ng add :

ng add @angular-architects/module-federation --project shell --port 4200 --type host
ng add @angular-architects/module-federation --project mfe1 --port 4201 --type remote

Si usas Nx, debes instalar la librería por separado. Después de eso, puede utilizar el flag :init

npm i @angular-architects/module-federation -D 
ng g @angular-architects/module-federation:init --project shell --port 4200 --type host
ng g @angular-architects/module-federation:init --project mfe1 --port 4201 --type remote

El argumento --type fue añadido en la versión 14.3 y asegura que sólo se genere la configuración necesaria.

Aunque es obvio que el shell del proyecto contiene el código del shell, mfe1 significa Micro Frontend 1, el comando mostrado hace varias cosas:

Generar una base de un webpack.config.js para usar Module Federation
Instalar un constructor personalizado haciendo que webpack dentro del CLI utilice el webpack.config.js generado.
Asigna un nuevo puerto para ng serve para que varios proyectos puedan ser servidos simultáneamente.

Ten en cuenta que el webpack.config.js es sólo una configuración parcial de webpack. Sólo contiene cosas para controlar module federation. El resto es generado por el CLI como siempre.

El Shell (Host)

Empecemos con el shell, que también se llama host en module federation, este utiliza el router para cargar de forma asyncronza el FlightModule:

export const APP_ROUTES: Routes = [
    {
      path: '',
      component: HomeComponent,
      pathMatch: 'full'
    },
    {
      path: 'flights',
      loadChildren: () => import('mfe1/Module').then(m => m.FlightsModule)
    },
];

Sin embargo, la ruta mfe1/Module que se importa aquí, no existe dentro del shell. Es sólo una ruta virtual que apunta a otro proyecto.

Para facilitar el compilador de TypeScript, necesitamos una definicion .d.ts para ello:

// decl.d.ts
declare module 'mfe1/Module';

Además, tenemos que decirle a webpack que todas las rutas que empiezan por mfe1 apuntan a otro proyecto. Esto se puede hacer en el webpack.config.js generado:

const { shareAll, withModuleFederationPlugin } = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({

  remotes: {
    "mfe1": "http://localhost:4201/remoteEntry.js",
  },

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },

});

La sección de remote asigna la ruta mfe1 al micro frontend a su entrada remota. Este es un pequeño archivo generado por webpack cuando se construye el remote, este es cargado en tiempo de ejecución para obtener toda la información necesaria para interactuar con el micro frontend.

Aunque especificar la URL de la entrada remota de esta manera es conveniente para el desarrollo, necesitamos un enfoque más dinámico para la producción.

El siguiente artículo de esta serie brindaremos una solución para esto: Dynamic Federation

La propiedad shared define los paquetes npm a compartir entre el shell y el/los micro frontend(s). Para esta propiedad, la configuración utiliza la propiedad shareAll que básicamente comparte todas las dependencias encontradas en su package.json. Si bien esto ayuda a obtener rápidamente una configuración , podría conducir a demasiadas dependencias compartidas.

Mas adelante hablaremos sobre este tema.

La combinación de singleton: true y strictVersion: true hace que webpack emita un error de ejecución cuando el shell y los micro frontend(s) necesiten diferentes versiones incompatibles (por ejemplo, dos versiones mayores diferentes). Si omitiéramos strictVersion o lo pusiéramos en false, webpack sólo emitiría una advertencia en tiempo de ejecución.

Hablaremos en otro articulos de como gestinoar las versiones en esta serie.

La propiedad requiredVersion: 'auto' es un pequeño extra proporcionado por el plugin @angular-architects/module-federation. Este busca la versión utilizada en tu package.json y evita varios problemas.

Al asignar el valor auto en requiredVersion, este remplaza el valor 'auto' con la versión encontrada en tu package.json.

El Micro frontend (aka Remote)

El Micro frontend también llamado remote en Module Federation el cual es una aplicacion de Angular ordinaria. Tiene rutas definidas dentro del AppModule:

export const APP_ROUTES: Routes = [
    { path: '', component: HomeComponent, pathMatch: 'full'}
];

Además, el FlightsModule:

@NgModule({
  imports: [
    CommonModule,
    RouterModule.forChild(FLIGHTS_ROUTES)
  ],
  declarations: [
    FlightsSearchComponent
  ]
})
export class FlightsModule { }

Este módulo tiene algunas rutas propias:

export const FLIGHTS_ROUTES: Routes = [
    {
      path: 'flights-search',
      component: FlightsSearchComponent
    }
];

Para que sea posible cargar el FlightsModule en el shell, también necesitamos exponerlo a través de la configuración de webpack del remote:

const { shareAll, withModuleFederationPlugin } = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({

  name: 'mfe1',

  exposes: {
    './Module': './projects/mfe1/src/app/flights/flights.module.ts',
  },

  shared: {
    ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),
  },

});

La configuración mostrada aquí expone el FlightsModule bajo el nombre público Module. La sección shared apunta a las librerias compartidas con el shell.

Iniciando el Micro frontend

Para probar todo, sólo tenemos que iniciar el shell y el micro frontend:

ng serve shell -o
ng serve mfe1 -o

Entonces, al hacer clic en Flights en el shell, se carga el micro frontend:

Sugerencia: También puedes usar el script npm run:all este se instala con schematics ng-add y init:

npm run run:all

Para iniciar sólo algunas aplicaciones, añada sus nombres como argumentos:

npm run run:all shell mfe1

Mirando los detalles

Vale, eso ha funcionado bastante bien. ¿Pero has echado un vistazo a tu main.ts?

Se parece a esto:

import('./bootstrap')
    .catch(err => console.error(err));

El código que normalmente se encuentra en el archivo main.ts fue trasladado al archivo bootstrap.ts. Todo esto fue hecho por el plugin @angular-architects/module-federation.

Aunque esto no parece tener mucho sentido a primera vista, es un patrón típico que se encuentra en las aplicaciones basadas en Module Federation. La razón es que Module Federation necesita decidir qué versión de una biblioteca compartida cargar. Si el shell, por ejemplo, está usando la versión 12.0 y uno de los micro frontends ya está construido con la versión 12.1, decidirá cargar esta última.

Para buscar los metadatos necesarios para tomar esta decision, Module Fedaration extra las importaciones dinámicas como esta de aquí. A diferencia de las importaciones estáticas más tradicionales, las importaciones dinámicas son asíncronas. Por lo tanto, Module Federation puede decidir sobre las versiones a utilizar y cargarlas realmente.

Más detalles: Compartir dependencias

Como se ha mencionado anteriormente, el uso de shareAll permite una primera configuración rápida que "simplemente funciona". Sin embargo, puede conducir a demasiados bundles compartidos. Dado que las dependencias compartidas no pueden treeshaken y por defecto terminan en bundles separados que necesitan ser cargados, es posible que desee optimizar este comportamiento cambiando de shareAll a share:

// Import share instead of shareAll:
const { share, withModuleFederationPlugin } = require('@angular-architects/module-federation/webpack');

module.exports = withModuleFederationPlugin({

    // Explicitly share packages:
    shared: share({
        "@angular/core": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common": { singleton: true, strictVersion: true, requiredVersion: 'auto' }, 
        "@angular/common/http": { singleton: true, strictVersion: true, requiredVersion: 'auto' },                     
        "@angular/router": { singleton: true, strictVersion: true, requiredVersion: 'auto' },
    }),

});

Conclusión

La implementación de Micro frontend ha implicado hasta ahora numerosos trucos y soluciones. Module Federation de Webpack proporciona por fin una solución sencilla y sólida para ello. Para mejorar el rendimiento, las librerias que pueden ser compartidas y se pueden configurar estrategias para tratar con versiones incompatibles.

También es interesante que los micro frontend sean cargados por Webpack y sin referencias en el código fuente del host o del remoto. Esto simplifica el uso de la Module Federation y el código fuente resultante, que no requiera frameworks de micro frontend adicionales.

Sin embargo, este enfoque también pone más responsabilidad en los desarrolladores. Por ejemplo, hay que asegurarse de que los componentes que sólo se cargan en tiempo de ejecución y que aún no se conocían en el momento de la compilación también interactúen como se desea.

También hay que lidiar con posibles conflictos de versión. Por ejemplo, es probable que componentes que fueron compilados con versiones de Angular completamente diferentes no funcionen juntos en tiempo de ejecución. Estos casos deben ser evitados con convenciones o al menos reconocidos lo antes posible con pruebas de integración.

La Revolución del Micro Frontend: Module Federation en Webpack 5

ng-content — Wed, 27 Jul 2022 05:04:00 +0000

Traducción en español del artículo original de Manfred Steyer "The Microfrontend Revolution: Module Federation in Webpack 5" publicado el 22 diciembre 2020

Module Federación viene integrado con Webpack a partir de la versión 5 y permite la carga de partes de una aplicacion compiladas por separado. Por lo tanto, finalmente proporciona una solución oficial para la implementación de micro frontends.

Hasta ahora, al implementar micro frontends, había que rebuscar y hace mucha magia. Una de las razones es seguramente que las herramientas de compilación y los frameworks no conocen este concepto. Module Federation inicia un cambio de rumbo en este sentido.

Module Federation presenta un enfoque para referenciar partes de una aplicacion que aún no se conocen en tiempo de compilación. Éstas pueden ser micro frontend autocompilados. Además, las partes individuales de la aplicacion pueden compartir bibliotecas entre sí, de modo que los paquetes individuales no contengan duplicados.

En este artículo, voy a mostrar cómo utilizar la Module Federación un ejemplo sencillo. El código fuente se puede encontrar aquí.

Ejemplo

El ejemplo utilizado aquí consiste en un shell, que es capaz de cargar micro frontend individuales, proporcionados por separado si es necesario:

La shell está representada aquí por la barra de navegación negra, el otro micro frontend en enmarcada, esta se puede iniciar sin un shell

Esto es necesario para permitir el desarrollo y las pruebas por separado. También para los clientes como los dispositivos móviles, que sólo tienen que cargar la aplicacion necesaria.

Conceptos de Module Federation

En el pasado, la implementación de escenarios como el mostrado aquí era difícil, especialmente porque herramientas como Webpack asumen que todo el código de la aplicacion está disponible cuando se compila. El Lazy loading es posible, pero sólo de las áreas que se separaron durante la compilación.

Con las arquitecturas de micro frontend queremos poder compilar y proporcionar las partes individuales de la aplicacion por separado. Además, hacer referencias mutuas a través de la respectiva URL. Por lo tanto, sería deseable contar con codigo como este:

import('http://other-microfrontend');

Como esto no es posible, había que recurrir a enfoques la carga manual de scripts. Afortunadamente, esto cambiará con el Module Federation en Webpack 5.

La idea detrás de esto es simple: Un llamado host hace referencia a un remoto usando un nombre configurado. A qué se refiere este nombre no se conoce en tiempo de compilación:

Esta referencia sólo se resuelve en tiempo de ejecución mediante la carga de un llamado punto de entrada remoto. Se trata de un script mínimo que proporciona la url externa real para dicho nombre configurado.

Implementación del Host

El host es una aplicación JavaScript que carga un remoto cuando se necesita. Para ello se utiliza una importación dinámica.

El host carga el componente mfe1/componente de esta manera mfe1 es el nombre de un remoto configurado y componente el nombre de un archivo que se proporciona.

const rxjs = await import('rxjs');

const container = document.getElementById('container');
const flightsLink = document.getElementById('flights');

rxjs.fromEvent(flightsLink, 'click').subscribe(async _ => {
    const module = await import('mfe1/component');
    const elm = document.createElement(module.elementName);
    […]    
    container.appendChild(elm);
});

Normalmente, Webpack tendría en cuenta esta referencia al compilar y dividiría un paquete separado para ella. Para evitarlo, se utiliza el ModuleFederationPlugin:

const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");

[…]
 output: {
      publicPath: "http://localhost:5000/",
      uniqueName: 'shell',
      […]
 },
plugins: [
  new ModuleFederationPlugin({
    name: "shell",
    library: { type: "var", name: "shell" },
    remoteType: "var",
    remotes: {
      mfe1: "mfe1"
    },
    shared: ["rxjs"]
  })
]

Con su ayuda se define el remoto mfe1 (Micro Frontend 1). La configuración mostrada aquí mapea el nombre interno de la aplicación mfe1 al mismo nombre oficial. Webpack no incluye ninguna importación que ahora se relacione con mfe1 en los paquetes generados en tiempo de compilación.

Las librerias que el host debe compartir con los remotes se mencionan en el array shared. En el caso mostrado, se trata de Rxjs. Esto significa que toda la aplicación sólo necesita cargar esta biblioteca una vez. Sin esta especificación, rxjs terminaría en los paquetes del host así como en los de todos los remotos.

Para que esto funcione sin problemas, el host y el remoto deben acordar una versión común.

Además de la configuración del ModuleFederationPlugin, también necesitamos colocar algunas opciones en la sección output. El publicPath define la URL bajo la cual la aplicación puede ser encontrada posteriormente. Esto revela dónde se pueden encontrar los paquetes individuales de la aplicación, pero también sus assets, por ejemplo, imágenes o estilos.

El uniqueName se utiliza para representar el host o remoto en los bundles generados. Por defecto, webpack utiliza el nombre de package.json para esto. Para evitar conflictos de nombres cuando se utiliza Monorepos con varias aplicaciones, se recomienda establecer el uniqueName manualmente.

Cargando Librerias compartidas

Para cargar librerias compartidas, debemos utilizar importaciones dinámicas:

const rxjs = await import('rxjs');

Al ser llamadas asincronas, esto le da a webpack el tiempo necesario para decidir qué versión usar y cargarla. Esto es especialmente importante en los casos en los que diferentes remotes y hosts utilizan diferentes versiones de la misma libreria. En general, webpack intenta cargar la versión más compatible.

Mas adelante hablaremos sobre la gestion de versiones entre micro frontends.

Para evitar este problema, es una buena idea cargar toda la aplicación con importaciones dinámicas en el punto de entrada utilizado. Por ejemplo, el micro frontend podría usar un main.ts que se vea así:

import('./component');

Esto le da a webpack el tiempo necesario para la negociación y la carga de las bibliotecas compartidas cuando la aplicación se inicia. Por lo tanto, en el resto de la aplicación siempre se pueden utilizar importaciones estáticas como:

import * as rxjs from 'rxjs';

Implementando el Remote

El remote también es una aplicación independiente y en este caso se basa en Web Components:

class Microfrontend1 extends HTMLElement {

    constructor() {
        super();
        this.attachShadow({ mode: 'open' });
    }

    async connectedCallback() {
        this.shadowRoot.innerHTML = `[…]`;
    }
}

const elementName = 'microfrontend-one';
customElements.define(elementName, Microfrontend1);

export { elementName };

En lugar de componentes web, también se puede utilizar cualquier component creados por un framework. En este caso, los frameworks deben ser compartidos entre los remotos y el host.

La configuración webpack del remote, que también utiliza el ` ModuleFederationPlugin ", exporta este componente con la propiedad exposes bajo el nombre component:

javascript output: { publicPath: "http://localhost:3000/", uniqueName: 'mfe1', […] }, […] plugins: [ new ModuleFederationPlugin({ name: "mfe1", library: { type: "var", name: "mfe1" }, filename: "remoteEntry.js", exposes: { './component': "./mfe1/component" }, shared: ["rxjs"] }) ]
El nombre del componente hace referencia al archivo. Además, esta configuración define el nombre mfe1 para el remoto. Para acceder a la remote, el host utiliza una ruta formada por los dos nombres configurados, mfe1 y component. El resultado es la instrucción que se muestra arriba:

typescript import('mfe1/component')
Sin embargo, el host debe conocer la URL en la que encuentra mfe1. La siguiente sección muestra cómo se puede lograr esto.

Conectar el host con el remoto

Para dar al host la opción de resolver el nombre mfe1, el host debe cargar un entryPoint del remoto. Este es un script que el ModuleFederationPlugin genera cuando se compila el remoto.

El nombre de este script se puede encontrar en la propiedad filename mostrada en la sección anterior. La url del micro frontend se toma de la propiedad publicPath. Esto significa que la url del remoto ya debe ser conocida cuando se compila.

Afortunadamente, ya existe un PR que elimina esta necesidad.

Ahora este script sólo debe ser integrado en el host:

`html

` En tiempo de ejecución se puede observar que la instrucción `typescript
import('mfe1/component');
`

Esto hace que el host cargue el remoto desde su propia url (que es localhost:3000 en nuestro caso):

Conclusión

Module Federation integrado en Webpack a partir de la versión 5 llena un gran vacío para los micro fronted. Por fin se pueden recargar las partes una aplicacion compiladas y suministradas por separado y reutilizar las librerias ya cargadas.

Sin embargo, los equipos que participan en el desarrollo de este tipo de aplicaciones deben asegurarse manualmente de que las partes individuales interactúan. Esto significa también que hay que definir y cumplir contratos entre los micro frontend individuales, pero también que hay que acordar una versión para cada una de las bibliotecas compartidas.

Hasta ahora, hemos visto que la Module Federation es una solución sencilla para crear micro frontends.

Photo by Clem Onojeghuo on Unsplash

Buenas Prácticas con NgRx: Parte 3 Modularidad

ng-content — Tue, 28 Jun 2022 16:53:00 +0000

Traducción en español del artículo original de Rainer Hahnekamp "NgRx Best Practices Series: 2. Modularity" publicado el 11 diciembre 2021

En esta serie de artículos, estoy compartiendo las lecciones que he aprendido de la construcción de aplicaciones reactivas en Angular utilizando la gestión de estado NgRx.

En la Parte 1 explicó cómo llegué a usar NgRx. Segunda parte mostraba cómo añadirle funcionalidad de caché. Aquí, veremos la gestión de estados desde un punto de arquitectura.

El código fuente está disponible en GitHub.

Modularidad: Contenedores, Presentación y Estado

Este patrón arquitectónico integra la gestión del estado en la conocida arquitectura de contenedor/presentación.

Creamos un módulo sólo para el código relevante para NgRx. A continuación, dividimos nuestros componentes en otros dos módulos. El primero contiene los componentes del contenedor que son responsables de la comunicación con el estado. El segundo contiene los componentes de presentación. Son responsables de la representación.

Tener tres módulos distintos con responsabilidades claras mejora enormemente la capacidad de mantenimiento de nuestra aplicación.

El problema subyacente no es nuevo y es muy conocido en otras áreas de la programación. Una clase/función/componente hace demasiadas cosas.

Si vemos un componente que se extiende por más de 100 líneas de código, probablemente hemos encontrado un ejemplar. Debido a ese tamaño, es difícil entender rápidamente su propósito. Esto hace que sea menos mantenible, y comprobable. Va en contra del principio de responsabilidad única.

Muy a menudo, encontramos lo mismo en el mundo Angular. Siempre hay un componente que contiene código no trivial junto con el HTML y el CSS. Ejemplos de código no trivial o "lógica" pueden ser el envío de acciones a NgRx, el uso del router, o alguna interacción con servicios.

Es importante saber que Comunicarse con NgRx es una cosa, renderizar es otra. No hagas todo eso en un solo componente. Un componente debe hacer sólo una cosa. Es renderizar o ejecutar la "lógica". Esa es la idea básica detrás del patrón de contenedores y componentes de presentación.

Así que tenemos un llamado componente de presentación que es responsable de la visualización. Consiste principalmente en HTML y CSS. En nuestro ejemplo, esto significaría mostrar la lista o el formulario del cliente.

El componente no sabe cómo obtener datos de NgRx. Ni siquiera sabe si se utiliza NgRx. Sólo obtiene su entrada a través de @Input(). Tampoco sabe qué debe ocurrir cuando el usuario hace clic en un botón de envío. Sólo emite un evento a través de @Output() y espera que alguien en la jerarquía del componente sepa qué hacer.

export class CustomerComponent {

formGroup = new FormGroup({});

@Input() customer: Customer | undefined;
@Output() save = new EventEmitter<Customer>();
@Output() remove = new EventEmitter<Customer>();

fields: FormlyFieldConfig[] = [

// form configuration

];

submit(customer: Customer) {

if (this.formGroup.valid) {
  this.save.emit(this.formGroup.value);
}

}

handleRemove(customer: Customer) {

  if (confirm(`Really delete ${customer}?`)) {
  this.remove.emit(this.customer);
}

}

}

Ese alguien es el componente contenedor. Es consciente del contexto. Sabe cómo tratar con NgRx, qué selectores son necesarios, cómo acceder a la ruta, etc. No sabe cómo se visualizan los datos. Simplemente los obtiene, los transforma y los transmite.

Un componente contenedor normalmente no tiene CSS, sólo un HTML mínimo. Ese HTML contiene el selector del componente de presentación subyacente.

El componente contenedor tampoco debe tener ningún enlace de entrada o salida. Como componente consciente del contexto, conoce su lugar en la aplicación, de dónde obtener todos los datos, y a quién llamar una vez que se produce un evento.

@Component({

selector: 'eternal-edit-customer',

template: ` <eternal-customer

*ngIf="customer$ | async as customer"

[customer]="customer"

(save)="this.submit($event)"

(remove)="this.remove($event)"

></eternal-customer>`,

})

export class EditCustomerComponent implements OnInit {

customer$: Observable<Customer> | undefined;

constructor(private store: Store, private route: ActivatedRoute) {}

ngOnInit() {

this.customer$ = this.store

.select(

fromCustomer.selectById(Number(this.route.snapshot.params.id || ''))

)

.pipe(

map((customer) => {

return { ...customer };

})

);

}

submit(customer: Customer) {

this.store.dispatch(

CustomerActions.update({ customer })

);

}
remove(customer: Customer) {
this.store.dispatch(
CustomerActions.remove({ customer })
);
}

}

Existen términos alternativos para este patrón. Algunos términos muy comunes son componente smart/dump.

Por supuesto, no siempre es posible adherirse a estas reglas estrictas. Habrá ocasiones en las que un componente de presentación necesite utilizar la inyección de dependencias de Angular. Por ejemplo, si quiere mostrar un formulario (como la pantalla de detalles del cliente), debería inyectar el FormBuilder.

Lo mismo ocurre con los componentes contenedores. Puede haber casos de uso válidos en los que reciba datos vía @Input de un componente padre. Pero, por favor, tratemos de evitar tener múltiples niveles de componentes contenedores anidados vinculados entre sí a través de la vinculación de propiedades.

¿Qué pasa con el State?

Dividir los componentes es la parte difícil. Lo que viene después es fácil. Los tipos de componentes obtienen sus propios módulos. Podemos llamar a los módulos con los componentes contenedores "feature" y al de las presentaciones "ui". Este es el esquema de nomenclatura que también utiliza nx (ver más abajo).

Lo mismo ocurre con el estado. Movemos todo el código NgRx relevante a un tercer módulo que se llama simplemente "data" (nx naming).

Casos especificos

Una ventaja inmediata perceptible es que ahora podemos reutilizar el mismo componente de formulario pero con un comportamiento diferente. El componente de presentación con el formulario es el mismo, independientemente de si se trata de editar o añadir un cliente.

Los componentes contenedores se encargan de las diferencias. Dependiendo de las diferencias entre la edición o la adición, podemos tener dos de ellos.

Así que terminamos con tres componentes. A primera vista puede parecer un exceso de trabajo. No es el caso. Los componentes son muy pequeños y sabemos inmediatamente dónde buscar cuando queremos cambiar la lógica para editar o añadir un cliente (componentes contenedores) o si queremos simplemente cambiar el formulario en sí (componente de presentación).

Pruebas más fáciles

Esta estricta separación también tiene otras ventajas. Podemos crear fácilmente pruebas unitarias para el componente contenedor.

Crear test unitarios en el front es muy difícil. El problema es la mezcla entre el código real y el HTML/CSS. Con los componentes contenedores, sólo queda el código. Es una clase normal con métodos y podemos escribir pruebas unitarias normales contra ella como lo haríamos en el backend.

Hay que decidir si es necesario probar la parte de código del componente de presentación. Podemos omitirla por completo o cambiar a una técnica de prueba especial como la Regresión Visual. Esta decisión dependerá muy probablemente de nuestro tipo de aplicación y de sus requisitos de calidad.

¿Más código = mejor?

Esto es para los lectores que acaban de empezar su carrera de programación: Dividir los componentes hace que nuestra base de código sea más fácil de mantener.

Para los desarrolladores principiantes, esto puede parecer contraintuitivo. Acabamos de hacer dos componentes -o incluso tres- en lugar de uno. Junto con toda la jerga de los componentes (declaración de clase TypeScript, metadatos @Component), podríamos terminar teniendo incluso más líneas de código que antes. ¿Por qué debería ser mejor?

El aumento del tamaño del código y una mejor mantenibilidad no son mutuamente excluyentes. Esto es normal. No eliminamos la complejidad, sólo la dividimos en unidades más pequeñas.

Es más fácil para nosotros si podemos trabajar en tres pequeños problemas en lugar de un gran problema. O dicho de otro modo, es más fácil trabajar con 3 archivos con 45 líneas de código en lugar de un archivo con 120 líneas de código.

Las clases son más cortas y las responsabilidades están claras. Si tenemos que buscar errores con el estado, buscamos en el módulo de estado. Si el diseño está roto, vamos al módulo de interfaz de usuario. Si el estado está bien pero los datos erróneos terminan en la UI, probablemente sea un error en el componente contenedor.

Forzando reglas con Nx

Sólo permitimos que los componentes contenedores hablen con NgRx. ¿Cómo se puede imponer esto?

Usamos nx, una extensión para el CLI de Angular, y usamos su función para definir reglas de dependencia. Ya está hecho.

A partir de ahora, cada vez que un componente de presentación intente usar algo del módulo de datos (=módulo relacionado con NgRx), obtendremos un error de linting y la compilación se romperá.

Pero eso no es todo. Podemos ir más allá. En NgRx, queremos que ciertas acciones sólo sean llamadas por los componentes del contenedor. Por ejemplo: Si usamos el patrón LoadStatus, entonces debe estar prohibido que cualquier componente fuera de NgRx despache el método load (o incluso loaded).

Para conseguirlo, el módulo de datos sólo exporta una lista limitada de acciones. Esta lista se define en su index.ts. Cualquier componente puede seguir accediendo a una acción no exportada haciendo referencia directa al archivo de acciones de NgRx. Pero esto se llama una importación profunda y nx intervendría aquí de nuevo y lanzaría un error de linting.

const removed = createAction(

'[CUSTOMER] Removed',

props<{ customers: Customer[] }>()

);

export const CustomerActions = {

get,
load,
loaded,
add,
added,
update,
updated,
remove,
removed,
};

export const PublicCustomerActions = {

get,
add,
update,
remove,
};

Acciones NgRx exponiendo un conjunto para uso interno y otro para público

export * from './lib/customer-data.module';
export { PublicCustomerActions as CustomerActions } from './lib/customer.actions';
export * from './lib/customer.selectors';

index.ts exponiendo sólo las acciones NgRx definidas en PublicCustomerActions

Los modelos

¿En cuál de los tres módulos debemos poner las interfaces que definen nuestros modelos de dominio? En ninguno. Si ponemos las interfaces en el módulo de estado o contenedor, nuestros componentes de UI no pueden tenerlas como valores de entrada o salida. A menos que nuestra aplicación sólo tenga una interfaz de usuario genérica, esto sería un problema.

Tampoco podemos añadir a la UI porque no queremos acoplar la gestión del estado con nuestra UI. Tenemos los componentes contenedores como mediadores.

El mejor lugar para los modelos sería un módulo propio en el que nuestros tres módulos tengan una dependencia.

El futuro

La siguiente parte de esta serie tratará un tipo de problema muy común. Queremos redirigir al usuario después de que un efecto haya enviado con éxito una solicitud al backend.

Otro caso de uso similar, basado en el mismo tipo de problema, es mostrar un mensaje de notificación después de una comunicación con el backend.

¿Quien debería hacerlo el effect, action? ¿Sería mejor en un componente? ¡Sigue atento para conocer la respuesta!

Foto de Worachat Sodsri en Unsplash

Buenas Prácticas con NgRx: Parte 2 Cache & LoadStatus

ng-content — Tue, 28 Jun 2022 16:52:00 +0000

En esta serie de artículos, estoy compartiendo las lecciones que he aprendido de la construcción de aplicaciones reactivas en Angular utilizando la gestión de estado NgRx.

En el artículo anterior, explique cómo llegué a usar NgRx. A continuación, compartiré las mejores prácticas en una aplicación de ejemplo "Eternal". Aquí, veremos la manera en que la gestión de estados te permite añadir funcionalidad de caché a tu código.

Parte 1: Cache y LoadStatus

Este patrón asegura que el store no cargue datos que ya tiene. En otras palabras: Añade una funcionalidad de caché.

Creamos este patrón en dos pasos. El estado obtiene una propiedad adicional llamada loadStatus, que emplea internamente para determinar si se requiere una petición a un endpoint.

Los ejemplos de State management suelen usar una acción
loady otra loaded para implementar una petición a un endpoint.

Nuestro patrón añade una tercera acción llamada get. Los componentes solo deben utilizar la acción get y es solo para uso interno en la gestión de estados.

El diagrama de abajo muestra a grandes rasgos en qué orden las acciones, los efectos y los reducers trabajan juntos para cargar los datos contra un estado vacío.

Si el estado ya tiene datos, los componentes pueden lanzar la acción get tantas veces como quieran, ya que no dará lugar a peticiones innecesarias:

Demostración

En nuestro ejemplo, hay un componente que lista a los clientes y otro componente que muestra un formulario detallado.

Ambos componentes necesitan lanzar el método load, estos necesitan los datos de los clientes y tienen que asegurarse de que se cargan.

Se podría argumentar que los usuarios siempre siguen el camino de la vista general a la vista detallada. Por lo tanto, debería ser suficiente que sólo la vista de lista despache la acción.

No podemos confiar únicamente en eso. Los usuarios pueden tener un enlace profundo directamente al formulario. Tal vez algunos otros componentes de la aplicación se vinculen directamente allí también.

Ahora tenemos el problema de que "hacer clic a través de la lista de usuarios" terminará creando un montón de llamadas innecesarias al endpoint.

Para solucionarlo, introducimos una propiedad loadStatus.

Los datos del store pueden estar en tres estados diferentes. Pueden no estar cargados, se pueden cargar, o están cargados. Además, sólo queremos renderizar nuestros componentes, cuando los datos están presentes.

El LoadStatus es un tipo de unión con tres valores diferentes. El estado lo tiene como propiedad y su valor inicial es "NOT_LOADED".

El estado cambia de

export interface State {

customers: Customer[];

}

const initialState = {

customers: []

}

export interface State {

loadStatus: 'NOT_LOADED' | 'LOADING' | 'LOADED';

customers: Customer[];

}

const initialState = {

loadStatus: 'NOT_LOADED',

customers: []

}

Introducimos una acción más, que llamamos get. Los componentes sólo utilizarán esa acción. A diferencia del método load, el get notifica al store que se solicitan los datos.

Un effect maneja ese método get. Comprueba el estado actual y, si el estado no es "LOADED", envía la acción load original. Ten en cuenta que la acción load es ahora una acción "interna". Los componentes o servicios nunca deben lanzarla.

Junto al effect que se ocupa de la acción de load, también tenemos un reducer adicional. Este establece el loadStatus a "LOADING". Esto tiene el el beneficio de que no pueden ocurrir peticiones paralelas. Eso está asegurado por diseño.

Lo último que tenemos que hacer es modificar nuestros selectores. Sólo deben emitir los datos si loadStatus se establece como LOADED. En consecuencia, nuestros componentes sólo pueden renderizar si los datos están totalmente disponibles.

Otras consideraciones

¿Por qué no podemos tomar un valor nulo en lugar del loadStatus como indicador de que el estado no se ha cargado todavía? Como consumidores del state , es posible que no conozcamos el valor inicial, por lo que sólo podemos adivinar si es nulo o no. Null puede ser en realidad el valor inicial que recibimos del backend. O puede ser algún otro valor. Teniendo un valor explícito de loadStatus, podemos estar seguros.

Lo mismo ocurre si se trata de un array. ¿Un array vacío significa que el almacén acaba de ser inicializado o significa que realmente no tenemos ningún dato? No queremos mostrar al usuario "Lo sentimos, no se han encontrado datos" cuando -en realidad- la petición espera la respuesta.

Casos avanzados

Con interfaces complejas, el store puede fácilmente recibir múltiples acciones en un periodo de tiempo muy corto. Cuando diferentes componentes disparan la accion de load, por ejemplo, todas estas acciones juntas construyen el estado que algún otro componente quiere mostrar.

Un caso de uso similar podría ser acciones encadenadas. Una vez más, un componente dependiente sólo quiere renderizar cuando la última acción ha terminado.

Sin la propiedad LoadStatus, el selector del componente emitiría cada vez que el estado cambie parcialmente. Esto puede resultar en un efecto de parpadeo poco amigable para el usuario.

En su lugar, los selectores deberían comprobar primero el LoadStatus antes de devolver los datos reales. Esto tiene la ventaja de que el componente obtiene los datos sólo una vez y en el momento adecuado, esto es muy eficiente y eficaz.

Extensiones

Si tenemos varios componentes que requieren los mismos datos y los componentes son todos hijos de la misma ruta, podemos utilizar un Guard para enviar la acción de obtención y esperar los datos.

En nuestro caso, tanto la lista como el detalle son hijos de "cliente". Así que nuestra guard se ve así:

@Injectable({

providedIn: 'root',

})

export class DataGuard implements CanActivate {

constructor(private store: Store<CustomerAppState>) {}

canActivate(): Observable<boolean> {

this.store.dispatch(CustomerActions.get());

return this.store

.select(fromCustomer.isLoaded)

.pipe(filter((isLoaded) => isLoaded));

}

}

Si realmente se busca la perfección, se podría incluso extraer el envío a un componente que se sitúe al lado del guard. La razón es que los guard deben ser pasivos y no tienen efectos secundarios.

Mejores prácticas relacionadas

En artículos posteriores, veremos las mejores prácticas relacionadas con nuestro ejemplo de almacenamiento en caché. Puede que también tengas algún contexto para esos datos, como un paginado asíncrono o una búsqueda.

Sea cual sea el contexto, la cuestión es que el frontend posee un subconjunto de datos que depende de ciertos "parámetros de filtrado" como la página actual. Si estos cambian, tenemos que encontrar una manera de invalidar la caché. Por favor, puede investigar más sobre esto.

En otro caso, podemos querer evitar que un consumidor active manualmente la accion de carga de datos con la llamada al endpoint. No podemos hacerlo a menos que encapsulemos la acción en un módulo propio y proporcionemos una interfaz para ella: Facade.

Perspectiva a futuro

El próximo artículo se centra en la arquitectura. Descubriremos cómo estructurar nuestra aplicación para que la gestión del estado pueda ser añadida como un módulo y cómo los componentes deben acceder a ello.

Traducción en español del artículo original de Rainer Hahnekamp NgRx Best Practices Series: 1. Cache & LoadStatus publicado el 23 agosto 2021

Buenas Prácticas con NgRx: Parte 1: Introducción

ng-content — Tue, 28 Jun 2022 16:50:00 +0000

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.

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

Foto de anthony renovato en Unsplash

Angular Standalone Components y su impacto en la modularidad

ng-content — Mon, 23 May 2022 11:44:24 +0000

Traducción en español del artículo original de Rainer Hahnekamp @rainerhahnekamp "Angular Standalone Components and their impact on modularity" publicado el 10 enero 2022

Una de las próximas características de Angular será "Standalone Components" (SC) y se puede ver también como "Optional NgModules". Esto eliminará la necesidad de NgModules.

Hay muchas entradas de blog, artículos, etc. sobre SC. Este artículo responde a una pregunta que no se discute tan a menudo: ¿Cómo afectará SC a la modularidad en una aplicación Angular?

La palabra NgModule contiene el término módulo, entonces cuando SC hacen que los NgModules sean opcionales o quizás los desapruebe a largo plazo, ¿significa eso que ya no tendremos módulos? Teniendo en cuenta que Angular es un framework empresarial, y el continuo esfuerzo del equipo de Angular por la estabilidad, esto sería un movimiento inesperado.

Empezaré con un resumen de lo que son los SC y las ventajas que aportan. Después me centro en la cuestión principal, es decir, si los NgModules opcionales y la modularidad forman una contradicción. La última parte trata de la mejor manera en que podemos prepararnos para SC en este momento.

El código fuente está disponible en GitHub.

Puedes ver la versión en vídeo en Inglés: https://youtu.be/rproG1_TCek

¿Qué son los Standalone Components?

Los debates en torno a los SC llevan varios meses en la comunidad. Igor Minar, uno de los desarrolladores clave detrás de Angular, dijo que había querido tratar con NgModules desde la primera versión beta de Angular. Esto fue en 2016. Por lo tanto, fue todo un acontecimiento cuando Pawel Kozlowski publicó la RFC oficial para Standalone Components en GitHub.

El elemento clave en Angular es el componente. Cada componente pertenece a un NgModule que proporciona las dependencias para él. Las declaraciones de propiedades del decorador de un NgModule crean esta relación.

Por ejemplo, si el componente requiere la directiva formGroup, el NgModule suministra esa directiva a través del ReactiveFormsModule.

La misma regla se aplica a los otros elementos visuales que son Pipe y Directive, para mayor simplicidad estos dos se incluyen cuando hablamos de un componente.

Esto no es únicamente una sobrecarga adicional. Dado ese vínculo adicional entre Componente y Módulo y el hecho de que un NgModule puede declarar múltiples componentes, no es tan fácil averiguar qué dependencias requiere un componente en particular.

Además de los componentes, también hay que tener en cuenta los Servicios y sus tres formas diferentes de proporcionarlos. El NgModule puede hacerlo, el componente puede hacerlo, o el Servicio podría proporcionarse a sí mismo a través de la propiedad providedIn. La última opción es la preferida y fue introducida en Angular 6.

Así, vemos que incluso un solo componente que contenga un formulario y un servicio implica un nivel de complejidad relativamente alto.

Los Standalone Components eliminan la capa adicional del NgModule.

El decorador de un componente recibirá propiedades adicionales para ello y proveer los servicios también será más fácil, ya que solo habrá dos opciones.

¿Cómo modularíamos nuestra aplicación con los componentes autónomos?

Aquí nos surgen unas preguntas. ¿Permiten los NgModules la modularidad en las aplicaciones Angular? Y si es así, ¿Deberíamos ahora escribir nuestras aplicaciones sin módulos?

Vamos a responder una a una.

¿Qué es un módulo?

Una buena definición de un módulo sería un grupo de elementos en una aplicación que pertenecen juntos. Hay diferentes posibilidades de "pertenecer juntos". Podría ser un grupo que contenga únicamente componentes de presentación, un grupo que contenga todos los elementos relevantes para el estado de NgRx, o algún otro criterio.

La funcionalidad más importante de un módulo es la encapsulación. Un módulo puede ocultar ciertos elementos del exterior. La encapsulación es clave para una arquitectura estable porque evita que cada elemento acceda a cualquier otro elemento.

¿Es NgModule un módulo?

Entonces, en ese sentido, ¿Es NgModule un módulo? Desafortunadamente, el NgModule cumple estos requisitos solo parcialmente. Proporciona encapsulación al menos para los elementos visuales (Componente, Directiva, Pipes) pero no puede imponerlos. Teóricamente, puedo crear un componente que extienda de uno encapsulado, crear un nuevo selector y voilà. Nada me impide acceder a una clase no exportada.

import { Component } from '@angular/core';
import { EncapsulatedComponent } from './module/encapsulated.component';

@Component({
 selector: 'app-stolen',
 templateUrl: './module/encapsulated.component.html',
})

export class StolenComponent extends EncapsulatedComponent {}

Ejemplo de un Componente extendido desde otro encapsulado

La cosa no mejora con los servicios. Como se ha descrito anteriormente, estos pueden vivir fuera del control de un NgModule.

Dado que los NgModules no pueden ofrecer una modularidad completa, ya podemos responder a la pregunta principal de este artículo: Los Standalone Components o los Módulos Opcionales no tendrán un impacto en la modularidad de una aplicación.

Sin embargo, ahora tenemos una nueva pregunta: ¿Qué deberíamos haber usado para los módulos en todo este tiempo?

¿Cómo implementar módulos en Angular?

Hay algo más en Angular además de NgModule, pero se disfraza con un nombre diferente. Es la librería o simplemente lib. Desde Angular 6, el CLI de Angular soporta la generación de librerías.

Una librería tiene su propia carpeta junto a la carpeta de la aplicación real. La librería también tiene un archivo llamado index.ts donde ocurre la encapsulación. Todo lo que se exporta desde ese index.ts se expone al exterior. Esto puede ser Servicios, Interfaces TypeScript, funciones, o incluso NgModules.

Una nota sobre los NgModules en las librerías: Hasta que SC esté disponible, seguimos necesitando el NgModule para exponer los componentes. Por eso una librería incluye también NgModules.

export { Lib1Module } from './lib/lib1.module';
export { ExposedComponent } from './lib/exposed.component';
export { RootProvidedService } from './lib/services/root-provided-service';
export { ExposedService } from './lib/services/exposed.service';

index.ts exponiendo NgModule

¿Qué pasa con la aplicación de la encapsulación?

Puede ocurrir en cualquier momento que un desarrollador importe un archivo no expuesto de una librería. Con un editor moderno eso puede ocurrir muy rápidamente. A menudo vemos esto cuando los elementos no expuestos se importan a través de una ruta relativa, mientras que los expuestos se importan utilizando el nombre de la librería.

Desafortunadamente, no hay nada en el CLI de Angular que nos impida hacer eso. Ahí es donde entra nx. Nx es una extensión de la CLI de Angular y proporciona, entre muchas características, una regla de linting para la modularidad. Esta regla de linting lanza un error si se produce la llamada importación profunda, es decir, el acceso directo a un archivo no expuesto.

Te recomiendo este excelente artículo en ingles para saber mas sobre Nx.

Nx proporciona otra regla de linting donde también podemos definir reglas de dependencia entre módulos. Podemos crear reglas como que el módulo A puede acceder al módulo B y C, pero el módulo B sólo puede acceder a C. Estas reglas también se validan mediante linting.

Por lo tanto, es la librería junto a nx y no el NgModule es la que cumple con todos los requisitos de un módulo.

¿Cómo me preparo mejor para la migración?

Todavía no tenemos SC, pero ¿podemos prepararnos ahora para que la migración sea lo más suave posible?

Durante bastante tiempo, y mucho antes de que se anunciaran los SC, el patrón Single Component Angular Module o "SCAM" ha sido popular en la comunidad. Con SCAM, un NgModule declara sólo un componente.

Si ya utilizas SCAM, el esfuerzo para migrar a SC será probablemente sólo mover las propiedades de los imports y providers al decorador @Component. Un script puede hacer esta tarea automáticamente. Puedes encontrar más información aquí.

¿Debe aplicar SCAM a una aplicación existente?

Si tienes una gran aplicación y un gran deseo de pasar a SC lo más rápido posible, entonces SCAM puede ayudarte a conseguirlo. En general, yo esperaría hasta que se publique SC.

También hay un shim que proporciona SC en este momento, aunque es sólo para fines de demostración y no es seguro para la producción.

Resumen

La gestión de la dependencias en Angular viene con diferentes variaciones y esto puede reducir potencialmente la consistencia, lo cual sera obstáculo para los recién llegados a Angular. El NgModule, en particular, crea una sobrecarga innecesaria y los componentes independientes (NgModules opcionales) eliminarán los NgModules y serán una gran mejora.

Los NgModules opcionales no tendrán esencialmente ningún impacto en la modularidad proporcionada por las librerías. Para las aplicaciones que siguen el patrón SCAM, un script puede hacer la migración automáticamente. Sin SCAM, tendrás que hacerlo manualmente.

Me gustaría dar las gracias a Pawel Kozlowski por revisar este artículo y proporcionar valiosos comentarios.

Nota personal: Gracias a Rainer por permitirme traducir a español su excelente contenido, que responde a muchas preguntas sobre Standalone Components.

Lecturas recomendadas:

En Español:
- Arquitectura de Component-First con Angular y Standalone Components

En Ingles:

Foto de Amélie Mourichon en Unsplash

Arquitectura de Component-First con Angular y Standalone Components

ng-content — Fri, 06 May 2022 09:45:00 +0000

Traducción en español del artículo original de Column Ferry @coly010 "Component-First Architecture with Angular and Standalone Components" publicado el 23 diciembre 2021

El equipo de Angular recientemente facilito un RFC(Solicitud de Comentarios) sobre los componentes independientes o mejor conocidos Standalone Components. Esto es un esfuerzo para hacer que los NgModules sean opcionales. Es importante enfatizar que los módulos no se van a eliminar por completo, ya que muchas aplicaciones de Angular tienen sus bases en NgModules.

Sobre este tema, Manfred Steyer ya ha empezado a explorar cómo podemos adoptarlo en nuestras aplicaciones, para saber más puedes mirarte su serie de artículos (En inglés): https://www.angulararchitects.io/en/aktuelles/angulars-future-without-ngmodules-part-2-what-does-that-mean-for-our-architecture/

Routing Declarativo

Yo creo que la mejor arquitectura que podemos lograr cuando los Standalone Components sean introducidos, es basarla en routing declarativo (Declarative Routing).

El Declarative Routing es un concepto que hemos visto implementado por paquetes como react-router. Esto significa declarar nuestras rutas como elementos en la plantilla de nuestro componente.

En Angular, no tenemos una solución de enrutamiento declarativo compatible oficialmente; sin embargo, Brandon Roberts ha creado un paquete que implementa este concepto en Angular Component Router.

Angular Component Router nos permite definir las rutas a través de nuestra aplicación en nuestros componentes, eliminando la necesidad de configurar el RouterModule en múltiples capas o módulos de nuestra aplicación.

Como los Standalone Components requieren que especifiquemos sus imports en su decorador @Component, esto podría volverse difícil de manejar. También significa que todavía dependemos de NgModules, lo que dificulta eliminarlos por completo de Angular.

Arquitectura Component-First

¿Qué pasa si simplemente usamos la plantilla de nuestro componente para definir las rutas a través de nuestra aplicación? Fácilmente, podríamos tener una API declarativa para el routing de nuestra aplicación que admita redireccionamientos, fallbacks, lazy loading componentes (¡punto importante!) y guards para las rutas.

Esto puede ir aún más lejos. En este momento, podemos definir rutas en cualquier componente de la aplicación, pero ver la configuración completa del routing de la aplicación puede ser complicado.

Con Standalone components, debemos dividir nuestra aplicación por features o dominios, es decir crearemos una estructura de carpetas/workspace en la que cada feature tenga su propia carpeta/librería y en su raíz de esta tenemos un route-entry que sirve de entrada y este contendrá las rutas para esta parte de la aplicación. Un ejemplo de estructura sería:

Podemos ver que tenemos un route-entry dominio/feature la raíz de nuestra aplicación y que definirá el enrutamiento para esa área de la aplicación. Ahora, cada quien sabrá exactamente dónde buscar cuando necesite encontrar, editar o agregar rutas al sistema.

A partir de aquí, nuestro routing principal únicamente debe apuntar a RouteEntryComonents.

Seguir este patrón con Standalone Components significa que nuestros componentes son la base principal de nuestras aplicaciones, como deberían ser.

En este punto, podemos decir que Component-First Architecture es donde nuestros componentes definen y manejan la experiencia del usuario en nuestra aplicación. Cualquier cosa que afecte la experiencia del usuario debe manejarse a través de nuestros componentes, ya que son nuestros componentes con los que interactúa el usuario.

¿Por qué debería importarnos Component-First?

Primero, es importante resaltar que Component-First tiene como objetivo crear un patrón arquitectónico que coloque a los componentes como la fuente de la verdad en nuestras aplicaciones de Angular.

Actualmente, los NgModules actúan casi como orquestadores, conectando la aplicación. Es a partir de los NgModules donde creamos la arquitectura AppModule -> FeatureModules -> SharedModules -> CoreModules.

Esta arquitectura está bien, ya que funciona, es escalable. ¿Pero es exagerado? Posiblemente.

Si bien ngModules presenta una gran separación dentro de la estructura de la aplicación, como CoreModules y SharedModules, pero con frecuencia se complican y son difíciles de mantener. Además, que SharedModules en particular puede convertirse en el cajón desastre, donde metemos todo y es conduce a una situación en la que necesitamos importar SharedModule a todos nuestros FeatureModules, incluso si uno necesita una simple directiva o un solo servicio.

Con Component-First, nuestros componentes deciden por sí mismos lo que necesitan realizar. Pueden inyectar dependencias a través de su constructor y pueden importar cualquier componente, directiva o pipe que necesiten para funcionar. Este mayor nivel de granularidad permite que nuestros componentes se concentren en su función, lo que reduce cualquier exceso que podría terminar compilado con el componente.

Otro punto a resaltar es que los componentes en una arquitectura Component-First son completamente tree-shakeable, eso quiere decir, si no se importan o enrutan, no se incluirán en el paquete final de nuestras aplicaciones. Actualmente, para lograr el mismo efecto con NgModules, podemos usar el patrón SCAM (Single Component Angular Module) que fue popularizado por Lars Gyrup Brink Nielsen.

Al seguir el patrón de arquitectura Component-First, también reducimos el acoplamiento entre nuestros componentes y NgModules, lo que prepara el camino hacia un Angular verdaderamente sin NgModules. Todavía podemos mantener la misma capacidad de composición que ofrece NgModules simplemente siguiendo algunas de las mejores prácticas al organizar nuestro código, algo que Angular ya nos tiene bien acostumbrados.

En resumen, si los componentes apuntan a componentes, nuestro mapa mental de nuestra aplicación se vuelve más simple y podemos ver la estructura de componentes en nuestra aplicación y nos permite tener una idea completa.

Dejaremos de preocuparnos de que NgModules agregue dependencias adicionales en sus componentes que quizás no esté esperando porque en Component-First, nuestros componentes dictan sus propias dependencias y esto reduce enormemente curva de aprendizaje y entendimiento, de nuestro código cuando alguien nuevo entra al equipo.

Foto de Olli Kilpi en Unsplash

Usando selectores correctos en Angular Testing Library

ng-content — Thu, 28 Apr 2022 14:19:00 +0000

Traducción en español del artículo original de Tim Deschryver Making sure you're using the correct query publicado el 28 marzo 2022

Uno de los principales puntos de enfoque de Testing Library es la accesibilidad. nosotros queremos asegurarnos de que los tests sean fáciles de escribir manteniendo la experiencia del usuario en primer lugar. En lugar de seleccionar elementos DOM a través de sus atributos o clases de identificación, Testing Library utiliza selectores querys que son fáciles de usar.

En las últimas versiones de DOM Testing Library y también de Angular Testing Library (versión 9), se han realizado mejoras en estos selectores. Aparece un selector en particular (get|find|query) ByRole.

Info la documentación:

Se puede usar para buscar cada elemento que se expone en el árbol de accesibilidad usando opción de name puede buscar los elementos devueltos por su nombre accesible.

Esta debería ser nuestra principal forma de buscar para casi todo. No hay nada que no se pueda conseguir con esto. (si no puedes, es posible tu interfaz tiene problemas de accesibilidad). En la mayoría de los casos la utilizaras de la siguiente manera: getByRole('button', {name: /submit/i}). Si quieres saber más puedes ver la lista de roles.

La respuesta corta a la pregunta "qué selector debo usar" en la mayoría de las veces es el selector ByRole, hay algunos casos en los que este selector no podrá encontrar el elemento, afortunadamente Testing Library proporciona un par de formas de encontrar un selector alternativo o "fallback". Antes de echar un vistazo a cómo a las alternativas, echemos un vistazo a otros beneficios, además de la accesibilidad, que resuelve ByRole.

Soluciones de ByRole

Seleccionar texto roto o con multiple tags

Los selectores ByText y *ByLabelText no pueden encontrar elementos que se dividen en varios elementos. Por ejemplo, dado el siguiente código HTML, es posible consultar el texto "Hello World".

<h3>Hello <span>World</span></h3>

Se puede resolver con la consulta ByRole de la siguiente manera:

// Before 
screen.getByText(/hello world/i)  
// |>Error: TestingLibraryElementError: Unable to find an element with the text: /hello world/i. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.  
// Using getByRole in version 9 
screen.getByRole('heading',  { name:  /hello world/i  })  
// |> HTMLHeadingElement

Buscando multiple elementos

Hubo momentos en que el selector usamos principalmente fue GetByText y este retorna más de un elemento. Esto provoca que algunas de nuestros tests fueran frágiles, que es lo que queremos evitar.

<h3>Login now</h3>
<button>Login</button>

Por ejemplo, para encontrar el botón de Login en el HTML anterior, seria de la siguiente forma:

const logins = screen.getAllByText(/login/i) 
const loginButton = logins[1]

Este test fallaría cuando se agregara un nuevo texto de "Login" en el componente. Esto no es bueno, ya que Testing Library tiene como objetivo escribir test mantenibles. Un mejor enfoque para este problema era utilizar la opción de selector.

const loginButton = screen.getByText(/login/i,  { selector:  'button'  })

Para este caso simple, este enfoque está bien. Pero esto podría causar problemas si se utilizan clases CSS como selector. Debido a que el selector ByRole es más explícita, reduce la posibilidad de encontrar varios elementos.

Si echamos un vistazo a la opción del selector, se parece a la consulta ByRole pero forzado usando con el getBy y selector. El selector ByRole es más robusta ya que no es demasiado específica, ejemplo: es posible encontrar etiquetas de encabezado con 'heading' en lugar de las etiquetas h1 a h6.

TIPS PARA ENCONTRAR EL SELECTOR CORRECTO

Lamentablemente, el ByRole no es la solución a todos tus problemas. Hay escenarios en los que no se puede utilizar la consulta *ByRole. Un ejemplo de esto son los elementos sin un rol, ejemplo. un campo de tipo password. Pero no nos preocuparemos, los selectores originales aún se pueden usar y también se aseguran de que la aplicación sea accesible.

Para encontrar el selector que necesita, hay varios recursos para usar.

La documentación

El sitio web de Testing Library tiene su propia página sobre los selectores. Si no has leído esto, te recomiendo que lo leas. Es un breve resumen, pero definitivamente lo ayudará a escribir mejores tests.

Testing Library Playground

Stephan Meijer creó testing-playground para ayudar a encontrar el "mejor" selector disponible. Para usarlo, copie y pegue el html en el editor y haga clic en los elementos representados o escriba los querys usted mismo.

Tambien esta disponible la extension Chrome y Firefox

Método configure de Testing Library

Recientemente se refactorizaron los ejemplos de Angular Testing Library para hacer uso de los selectores ByRole. Hice esto usando la opción recién agregada throwSuggestions al método de configure. Esta desactivado por defecto, pero es posible activarlo a nivel global o por selector. Como su nombre lo indica, arrojará un error si hay una consulta mejor/más segura disponible.

Como ejemplo, podemos tomar el siguiente HTML y hacer el test de hacer clic en el botón de Increment.

<button (click)="value = value - 1">Decrement</button>  
<span data-testid="value">{{ value }}</span>  
<button (click)="value = value + 1">Increment</button>

import  { render, screen, fireEvent, configure }  from  '@testing-library/angular'  
import  { CounterComponent }  from  './counter.component'  

    beforeEach(()  =>  {  
        configure({ throwSuggestions:  true,  }) 
    })  
    test('renders the current value and can increment',  async  ()  =>  {  
        await  render(CounterComponent)  
        const incrementControl = screen.getByText('Increment')
        fireEvent.click(incrementControl) 
    })

Debido a que throwSuggestions está activado, obtenemos el siguiente error mientras ejecutamos él test.

TestingLibraryElementError: A better query is available, try this: 
getByRole("button", {name: /increment/i})

Testing Library nos brinda un mejor selector que podemos copiar y pegar en el test para reemplazar el uso de selectores "incorrectos".

test('renders the current value and can increment',  
async  ()  =>  {  
    await  render(CounterComponent)  
    const incrementControl = screen.getByRole('button', { name: /increment/i }) 
    fireEvent.click(incrementControl) 
})

¿Simple verdad? Para activarlo o desactivarlo para un selector específico podemos hacer lo siguiente, que tendrá el mismo resultado.

    test('renders the current value and can increment', async () => {
      await render(CounterComponent)
     const incrementControl = screen.getByText('Increment', { suggest: true })  
     fireEvent.click(incrementControl)
    })

Mensajes de Testing Library

Testing Library muestra un mensaje útil cuando no encuentra un elemento en el selector ByRole . Veamos el ejemplo a continuación, donde cada elemento accesible se registra con su selector correspondiente.

TestingLibraryElementError: Unable to find an accessible element with the role "textbox" and name `/increment/i`
Here are the accessible roles:

    button:

    Name "Decrement":
    <button />

    Name "Increment":
    <button />

    Name "Login":
    <button />

    --------------------------------------------------
    heading:

    Name "Login now":
    <h3 />

    --------------------------------------------------

TIPS PARA ANGULAR TESTING LIBRARY

screen

En versiones anteriores de Angular Testing Library, sólo era posible consultar elementos a través de objectos devueltos por el método render. En la versión 9 de Angular Testing Library, se exporta un objeto screen que tiene todos los selectores disponibles. Esto tiene como beneficio que tus tests serán más simples. Un segundo beneficio es que también busca elementos fuera del HTML del componente. Esto puede ser particularmente útil si estás usando Angular Material porque añadirán elementos al cuerpo del documento y fuera del árbol del componente.

import { screen } from '@testing-library/angular'

test('renders the current value and can increment', async () => {
-  const { getByRole } = await render(CounterComponent)
+  await render(CounterComponent)

-  const incrementControl = getByRole('button', { name: /increment/i })
+  const incrementControl = screen.getByRole('button', { name: /increment/i })
})

fireEvent

Para disparar eventos se recomienda utilizar el nuevo objeto fireEvent en lugar de utilizar los eventos devueltos por el método render. Los eventos disparados por fireEvent también ejecutarán un ciclo de detección de cambios, al igual que antes.

import { fireEvent } from '@testing-library/angular'

test('renders the current value and can increment', async () => {
-  const { click } = await render(CounterComponent)
+  await render(CounterComponent)

-  click(incrementControl)
+  fireEvent.click(incrementControl)
})

find

La versión 9 Testing Library, también arregla los selectores de búsqueda e invocará un ciclo de detección de cambios antes de invocar la consulta. Esto puede ser útil para el código asíncrono que impacta el DOM. Por ejemplo, si input de texto modificado y va a renderizar algo después. Mientras que antes había que llamar manualmente a detectChanges.

- test('shows the load button after text input', fakeAsync(async () => {
+ test('shows the load button after text input', async () => {
  const { detectChanges } = await render(FixtureComponent, {
    imports: [ReactiveFormsModule],
  });

  userEvent.type(screen.getByRole('textbox'), 'What a great day!');

-  tick(200);
-  detectChanges();
-  screen.getByRole('button');
+  screen.findByRole('button');
-}));
+});

Extras

Kent C. Dodds escribió Errores comunes con React Testing Library , la mayoría de los consejos también se aplican a Angular Testing Library. Así que, ¡léanlo para obtener más consejos útiles para escribir sus test con Testing Library!

Nota: Si te ha gustado compartelo.

Foto de Masjid Pogung Dalangan en Unsplash

Escribiendo menos tests y más largos

ng-content — Mon, 25 Apr 2022 07:24:00 +0000

Traducción en español del artículo original de Kentc dodds Write fewer, longer tests publicado el 26 Augusto 2019

Imagine que tenemos esta interfaz de usuario que muestra un spinner de carga hasta que se cargan algunos datos:

import * as React from 'react'
import * as api from './api'

function Course({courseId}) {
  const [state, setState] = React.useState({
    loading: false,
    course: null,
    error: null,
  })

  const {loading, course, error} = state

  React.useEffect(() => {
    setState({loading: true, course: null, error: null})
    api.getCourseInfo(courseId).then(
      data => setState({loading: false, course: data, error: null}),
      e => setState({loading: false, course: null, error: e}),
    )
  }, [courseId])

  return (
    <>
      <div role="alert" aria-live="polite">
        {loading ? 'Loading...' : error ? error.message : null}
      </div>
      {course ? <CourseInfo course={course} /> : null}
    </>
  )
}

function CourseInfo({course}) {
  const {title, subtitle, topics} = course
  return (
    <div>
      <h1>{title}</h1>
      <strong>{subtitle}</strong>
      <ul>
        {topics.map(t => (
          <li key={t}>{t}</li>
        ))}
      </ul>
    </div>
  )
}

export default Course

Hablemos de probar este componente. Voy a simular la llamada api.getCourseInfo(courseId) para que en realidad no hagamos ninguna solicitud de red para este test. Estas son algunas de las cosas que necesitaremos hacer test, para asegurarnos que funciona:

Debe mostrar una rueda de cargando.
Debería llamar a la función getCourseInfo correctamente.
Debería mostrar el título.
Debería mostrar el subtítulo.
Deberías mostrar la lista de temas del curso.

Luego están los casos del error (Cuando la petición falla):

Debe mostrar una rueda de cargando.
Debería llamar a la función getCourseInfo correctamente.
Debería mostrar el mensaje de error.

Muchas personas leen esa lista de requisitos para el test de un componente y los convierten en casos de prueba individuales. Tal vez haya leído acerca de algo que dice "Confirmar una sola vez por test, es una buena práctica". Vamos a tratar de hacerlo:

// 🛑 ESTE ES UN EJEMPLO DE COMO NO SE DEBERIA HACER !! 
import * as React from 'react'
import {render, wait, cleanup} from '@testing-library/react/pure'
import {getCourseInfo} from '../api'
import Course from '../course'

jest.mock('../api')

function buildCourse(overrides) {
  return {
    title: 'TEST_COURSE_TITLE',
    subtitle: 'TEST_COURSE_SUBTITLE',
    topics: ['TEST_COURSE_TOPIC'],
    ...overrides,
  }
}

describe('Course success', () => {
  const courseId = '123'
  const title = 'My Awesome Course'
  const subtitle = 'Learn super cool things'
  const topics = ['topic 1', 'topic 2']

  let utils
  beforeAll(() => {
    getCourseInfo.mockResolvedValueOnce(buildCourse({title, subtitle, topics}))
  })

  afterAll(() => {
    cleanup()
    jest.resetAllMocks()
  })

  it('should show a loading spinner', () => {
    utils = render(<Course courseId={courseId} />)
    expect(utils.getByRole('alert')).toHaveTextContent(/loading/i)
  })

  it('should call the getCourseInfo function properly', () => {
    expect(getCourseInfo).toHaveBeenCalledWith(courseId)
  })

  it('should render the title', async () => {
    expect(await utils.findByRole('heading')).toHaveTextContent(title)
  })

  it('should render the subtitle', () => {
    expect(utils.getByText(subtitle)).toBeInTheDocument()
  })

  it('should render the list of topics', () => {
    const topicElsText = utils
      .getAllByRole('listitem')
      .map(el => el.textContent)
    expect(topicElsText).toEqual(topics)
  })
})

describe('Course failure', () => {
  const courseId = '321'
  const message = 'TEST_ERROR_MESSAGE'

  let utils, alert
  beforeAll(() => {
    getCourseInfo.mockRejectedValueOnce({message})
  })

  afterAll(() => {
    cleanup()
    jest.resetAllMocks()
  })

  it('should show a loading spinner', () => {
    utils = render(<Course courseId={courseId} />)
    alert = utils.getByRole('alert')
    expect(alert).toHaveTextContent(/loading/i)
  })

  it('should call the getCourseInfo function properly', () => {
    expect(getCourseInfo).toHaveBeenCalledWith(courseId)
  })

  it('should render the error message', async () => {
    await wait(() => expect(alert).toHaveTextContent(message))
  })
})

Definitivamente recomiendo en contra de este enfoque de prueba. Hay algunos problemas con eso:

Los tests no son para nada aislados. (read Test Isolation with React Inglés)
Las mutaciones de variables se comparten entre tests (read Avoid Nesting when you're Testing Inglés)
Pueden ocurrir cosas asincrónicas entre los test, lo que hace que reciba warnings de "act".

Nos queda claro que los primeros dos puntos son aplicables independientemente de lo que esté probando. El tercero es un pequeño detalle de implementación entre jest y act.

En cambio, sugiero que combinemos los tests así:

// ✅ Este es un ejemplo de cómo hacer las cosas.
import {render, screen, wait} from '@testing-library/react'
import * as React from 'react'

import {getCourseInfo} from '../api'
import Course from '../course'

jest.mock('../api')

afterEach(() => {
  jest.resetAllMocks()
})

function buildCourse(overrides) {
  return {
    title: 'TEST_COURSE_TITLE',
    subtitle: 'TEST_COURSE_SUBTITLE',
    topics: ['TEST_COURSE_TOPIC'],
    ...overrides,
  }
}

test('course loads and renders the course information', async () => {
  const courseId = '123'
  const title = 'My Awesome Course'
  const subtitle = 'Learn super cool things'
  const topics = ['topic 1', 'topic 2']

  getCourseInfo.mockResolvedValueOnce(buildCourse({title, subtitle, topics}))

  render(<Course courseId={courseId} />)

  expect(getCourseInfo).toHaveBeenCalledWith(courseId)
  expect(getCourseInfo).toHaveBeenCalledTimes(1)

  const alert = screen.getByRole('alert')
  expect(alert).toHaveTextContent(/loading/i)

  const titleEl = await screen.findByRole('heading')
  expect(titleEl).toHaveTextContent(title)

  expect(screen.getByText(subtitle)).toBeInTheDocument()

  const topicElsText = screen.getAllByRole('listitem').map(el => el.textContent)
  expect(topicElsText).toEqual(topics)
})

test('an error is rendered if there is a problem getting course info', async () => {
  const message = 'TEST_ERROR_MESSAGE'
  const courseId = '321'

  getCourseInfo.mockRejectedValueOnce({message})

  render(<Course courseId={courseId} />)

  expect(getCourseInfo).toHaveBeenCalledWith(courseId)
  expect(getCourseInfo).toHaveBeenCalledTimes(1)

  const alert = screen.getByRole('alert')
  expect(alert).toHaveTextContent(/loading/i)

  await wait(() => expect(alert).toHaveTextContent(message))
})

Ahora nuestros tests están completamente aislados, ya no hay referencias de variables mutables compartidas, hay menos anidamiento, por lo que leer el test es más fácil y ya no recibiremos la advertencia de act de React.

Sí, hemos violado de "un assert por test", pero esa regla se creó originalmente porque frameworks mal trabajo de brindarnos un poco de información y tú necesitas determinar que está causando este error, cuando este falle verás algo así:

FAIL  src/__tests__/course-better.js
  ● course loads and renders the course information

    Unable to find an element with the text: Learn super cool things. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.

    <body>
      <div>
        <div
          aria-live="polite"
          role="alert"
        />
        <div>
          <h1>
            My Awesome Course
          </h1>
          <ul>
            <li>
              topic 1
            </li>
            <li>
              topic 2
            </li>
          </ul>
        </div>
      </div>
    </body>

      40 |   expect(titleEl).toHaveTextContent(title)
      41 |
    > 42 |   expect(getByText(subtitle)).toBeInTheDocument()
         |          ^
      43 |
      44 |   const topicElsText = getAllByRole('listitem').map(el => el.textContent)
      45 |   expect(topicElsText).toEqual(topics)

      at getElementError (node_modules/@testing-library/dom/dist/query-helpers.js:22:10)
      at node_modules/@testing-library/dom/dist/query-helpers.js:76:13
      at node_modules/@testing-library/dom/dist/query-helpers.js:59:17
      at Object.getByText (src/__tests__/course-better.js:42:10)

Y la terminal, también se resaltará la sintaxis:

Gracias a nuestras increíbles herramientas, identificar qué assert fallo es fácil. ¡Ni siquiera te dije lo que rompí, pero apuesto a que sabrás dónde buscar si esto te sucediera! Y puede evitar los problemas descritos anteriormente. Si desea dejar las cosas aún más claras, puede agregar un comentario en el código de la assert para explicar que tan importante es o que está haciendo.

Conclusión

No se preocupe por tener tests largos. Cuando está pensando en sus dos usuarios y evita al usuario de prueba, porque entonces sus test a menudo involucrarán múltiples afirmaciones y eso es algo bueno. No separe arbitrariamente sus assert en bloques de tests individuales, no hay una buena razón para hacerlo.

Debo señalar que no recomendaría renderizar el mismo componente varias veces en un solo bloque del test (las re-renderizaciones están bien si está probando lo que sucede en las actualizaciones props, por ejemplo).

Recuerde el siguiente principio:

Piense en un test, como si fuera un tester manual e intente hacer que cada uno de sus casos de prueba incluya todas las partes de ese proceso. Esto a menudo da como resultado múltiples acciones y afirmaciones, lo cual está bien.

Existe el antiguo modelo "Arrange", "Act", "Assert" para estructurar los tests. Por lo general, sugiero que tenga un únicamente "Arrange" por tests, y tantos "Act" y "Assert" como sea necesario para que el test cubra el proceso y le genere confianza sobre lo testeado.

Github Repo con ejemplos

EXTRAS:

Todavía recibo la advertencia de `act`, aunque estoy usando las React Testing Library.

La utilidad act de React está integrada en la React Testing library. Hay muy pocas veces que debería tener que usarlo directamente si está usando los async de React Testing Library.

Cuando utilice jest.useFakeTimers()
Cuando utilice useImperativeHandle y llame funciones que llaman a los actualizadores de estado directamente.
Al probar hooks personalizados que emplee funciones, directamente que llaman a los actualizadores de estado.

En cualquier otro momento, debería estar resuelto por React Testing Library. Si todavía tienes la advertencia de act, entonces la razón más probable es que algo esté sucediendo después de que se complete el test, por lo que debería estar esperando.

Aquí hay un ejemplo de un test (usando el mismo ejemplo anterior) que sufre este problema:

// 🛑 ESTE ES UN EJEMPLO DE COMO NO HACERLO...
test('course shows loading screen', () => {
  getCourseInfo.mockResolvedValueOnce(buildCourse())
  render(<Course courseId="123" />)
  const alert = screen.getByRole('alert')
  expect(alert).toHaveTextContent(/loading/i)
})

Aquí estamos renderizando el componente Course y tratando de verificar que el mensaje de carga se muestre correctamente. El problema es que cuando renderizamos el componente , inmediatamente lanza una solicitud asíncrona. Nos estamos mockeando correctamente esta solicitud (que lo estamos haciendo, de lo contrario, nuestro test realmente hará la solicitud). Sin embargo, nuestra prueba se completa sincrónicamente antes de que la solicitud mock tenga la oportunidad de resolverse. Cuando finalmente lo hace, se llama a nuestro handler, que llama a la función de actualización de estado y recibimos la advertencia de act.

Hay tres formas de arreglar esta situación:

Esperar a que la promesa se resuelva.
Use wait de React Testing Library
Ponga esta assert en otra prueba (la premisa de este artículo).

// 1. Esperando que la promesa se resuelva
// ⚠️ Esta es una buena manera de resolver este problema, pero hay una mejor manera, sigue leyendo
test('course shows loading screen', async () => {
  const promise = Promise.resolve(buildCourse())
  getCourseInfo.mockImplementationOnce(() => promise)
  render(<Course courseId="123" />)
  const alert = screen.getByRole('alert')
  expect(alert).toHaveTextContent(/loading/i)
  await act(() => promise)
})

Esto en realidad no es tan malo. Recomendaría esto si no hay cambios observables en el DOM. Tuve una situación como así en una interfaz de usuario que construí donde implementé una actualización optimista (lo que significa que la actualización del DOM ocurrió antes de que finalizara la solicitud) y, por lo tanto, no tenía forma de esperar/afirmar los cambios en el DOM.

// 2. usando `wait` de react testing library
test('course shows loading screen', async () => {
  getCourseInfo.mockResolvedValueOnce(buildCourse())
  render(<Course courseId="123" />)
  const alert = screen.getByRole('alert')
  expect(alert).toHaveTextContent(/loading/i)
  await wait()
})

Esto realmente solo funciona si el mock que ha creado se resuelve de inmediato, lo cual es muy probable (especialmente si está utilizando mockResolvedValueOnce). Aquí no tiene que usar act directamente, pero este test básicamente ignora todo lo que sucedió durante ese tiempo de espera, por lo que realmente no lo recomiendo.

La última (y mejor) recomendación que tengo para ti es que incluyas esta afirmación en las otras pruebas de tu componente. No hay mucho valor en mantener esta afirmación por sí sola.

Puedes ver el código final en GitHub

Nota personal: Esta solución no es solo para React, la razon por lo cual hice la traducción es porque es un contenido super importante, en mi caso he implementado lo mismo usando Testing Library en Angular.

Si te gusto el contenido, no dudes compartirlo.

Photo by Cathryn Lavery on Unsplash

Obteniendo el mayor valor de nuestros tests en Angular

ng-content — Sun, 24 Apr 2022 19:24:00 +0000

Traducción en español del artículo original de Tim Deschryver Getting the most value out of your Angular Component Tests publicado el 21 marzo 2022

Con frecuencia escucho que es difícil saber qué probar o hacer tests un componente en Angular. Esta queja a menudo se menciona junto con el hecho de que lleva mucho tiempo escribir y mantener hacer tests además que brindan poco o ningún valor. Al final, el equipo se pregunta si los tests valen la pena.

He estado en esta situación antes y hay dos síntomas para llegar a este punto. Casi no tiene tests, o al contrario, el código está inflado con tests que lo ralentizan. Ambas opciones no son buenas.

En esta publicación, quiero compartir cómo creo que podemos obtener el máximo valor de nuestros tests. Pero, ¿qué es un test que aporte valor? Para mí, significa que el test puede prevenir un error en mi código (¡un poco obvio!). Pero también que el costo de escribir un test no obstaculice el proceso de desarrollo, ahora o en el futuro. En otras palabras, el test no tiene que sentirse como una tarea para escribir. En cambio, el test debe ser fácil de leer y debe ayudarme a enviar nuevas funciones con confianza.

Para lograr esto, quiero imitar de al usuario que usa mi aplicación. También significa que se hace lo más similar a él, porque ¿de qué otra manera podemos asegurar que la aplicación funciona como se espera?

Para ayudarme a escribir estos tests, estoy usando Testing library para Angular. Cuando usa Testing library, solo necesita el método render y el objeto screen para probar los aspectos básicos de nuestro componente. Para las interacciones con el componente, también uso userEvent de [@testing-library/user-event](https://testing-library.com/docs/ecosystem-user-event/).

Echemos un vistazo al primer test de un componente simple llamado EntitiesComponent. El componente contiene una colección de entidades y se encarga de mostrar las entidades en una tabla.

import { render, screen } from '@testing-library/angular';

it('renders the entities', async () => {
  await render(EntitiesComponent);

  expect(screen.getByRole('heading', { name: /Entities Title/i })).toBeDefined();

  // Uso los matchers de  @testing-library/jest-dom
  // para hacerlos fácil de leer
  // ejemplo remplazo `toBeDefined` con `toBeInTheDocument`
  expect(screen.getByRole('cell', { name: /Entity 1/i })).toBeInTheDocument();
  expect(screen.getByRole('cell', { name: /Entity 2/i })).toBeInTheDocument();
  expect(screen.getByRole('cell', { name: /Entity 3/i })).toBeInTheDocument();
});

Aquí puede ver el primer uso del objeto screen. Puede pensar en screen como la pantalla real que vería un usuario final (los nodos del DOM), que contiene múltiples [querys](https://testing-library.com/docs/queries/about/#types-of-queries) para verificar que el componente se presenta correctamente. La query más importante es byRole, le permite seleccionar el elemento tal como lo haría un usuario (o lector de pantalla). Debido a esto, tiene el beneficio adicional de hacer que sus componentes sean más accesibles.

SUGERENCIA: use screen.debug() para registrar el HTML en la consola, o use screen.logTestingPlaygroundURL() un link interactivo para saber que selectores usar. Por ejemplo, la aplicación de ejemplo que se usa en este artículo está disponible con este vínculo de play ground, el PlayGround nos permite usar el selector correcto.

Bastante simple y legible, ¿verdad? Por supuesto, es solo un componente simple, por lo que test también debería ser simple.

Agreguemos algunos extras al componente y veamos qué impacto tiene esto en test. En lugar de una colección de entidades estáticas, el componente ahora recupera las entidades con un servicio y usa un componente de tabla (TableComponent) para representar las entidades.

import { render, screen } from '@testing-library/angular';

it('renders the entities', async () => {
    await render(EntitiesComponent, {
        declarations: [TableComponent],
        providers: [
            {
                provide: EntitiesService,
                value: {
                    fetchAll: jest.fn().mockReturnValue([...])
                }
            }
        ]
    });

    expect(
        screen.getByRole('heading', { name: /Entities Title/i })
    ).toBeInTheDocument();

    expect(
        screen.getByRole('cell', { name: /Entity 1/i })
    ).toBeInTheDocument();
    expect(
        screen.getByRole('cell', { name: /Entity 2/i })
    ).toBeInTheDocument();
    expect(
        screen.getByRole('cell', { name: /Entity 3/i })
    ).toBeInTheDocument();
})

Vemos que debido a cómo se escribió previamente el test del componente, no hay grandes cambios en el test. La única parte que se ve afectada es la configuración del test. El test no contiene los detalles internos del componente, por lo que es más fácil refactorizar el componente sin tener que preocuparse por volver tocar el test.

Si te gusta Angular TestBed, la configuración adicional de método render (el segundo argumento) debe sonarte familiar. Esto se debe a que render es un contenedor simple alrededor de TestBed y la API se mantiene idéntica, con algunos valores predeterminados.

En el test, el servicio EntitiesService se mockea para evitar que el test realice una solicitud de red real. Mientras escribimos los tests de componentes, no queremos que las dependencias externas afecten el test. En cambio, queremos tener control sobre los datos. El stub devuelve la colección de entidades que se proporcionan durante la configuración del test. Otra posibilidad sería usar Mock Service Worker (MSW). MSW intercepta solicitudes de red y las reemplaza con una implementación simulada. Un beneficio adicional de MSW es que los mocks creados se pueden reutilizar en aplicación durante el desarrollo o durante los tests end to end.

Con la funcionalidad básica escrita, creo que es hora de interactuar con el componente. Agreguemos un cuadro de texto de búsqueda para filtrar las entidades en la tabla y ajustar el test para verificar la lógica.

import {
    render,
    screen,
    waitForElementToBeRemoved,
} from '@testing-library/angular';
import userEvent from '@testing-library/user-event';

it('renders the entities', async () => {
    await render(EntitiesComponent, {
        declarations: [TableComponent],
        providers: [
            {
                provide: EntitiesService,
                value: {
                    fetchAll: jest.fn().mockReturnValue([...])
                }
            }
        ]
    });

    expect(
        screen.getByRole('heading', { name: /Entities Title/i })
    ).toBeInTheDocument();

    expect(
        screen.getByRole('cell', { name: /Entity 1/i })
    ).toBeInTheDocument();
    expect(
        screen.getByRole('cell', { name: /Entity 2/i })
    ).toBeInTheDocument();
    expect(
        screen.getByRole('cell', { name: /Entity 3/i })
    ).toBeInTheDocument();

    userEvent.type(
        screen.getByRole('textbox', { name: /Search entities/i }),
        'Entity 2'
    );

    // dependiendo de la implementacion podemos usar
    // waitForElementToBeRemoved para esperar que el elemento se sea removido o usar el selector  queryBy
    await waitForElementToBeRemoved(
        () => screen.queryByRole('cell', { name: /Entity 1/i })
    );
    expect(
        screen.queryByRole('cell', { name: /Entity 1/i })
    ).not.toBeInTheDocument();

    expect(
        await screen.findByRole('cell', { name: /Entity 2/i })
    ).toBeInTheDocument();
})

Para simular un usuario que interactúa con el componente, use los métodos en el objeto userEvent. Estos métodos replican los eventos de un usuario real. Por ejemplo, para el método de type, se activan los siguientes eventos: focus, keyDown, keyPress, input y keyUp. Para los eventos que no están disponibles en userEvent, puede usar fireEvent de @testing-library/angular. Estos eventos son representaciones de eventos JavaScript reales que se envían al control.

El test también incluye el uso de un nuevo método, waitForElementToBeRemoved. El método waitForElementToBeRemoved solo debe usarse cuando un elemento se elimina de forma asíncrona del documento. Cuando el elemento se elimina inmediatamente, no tiene que esperar hasta que se elimine, por lo que puede usar el selector queryBy y confirmar que el elemento no existe en el documento.

La diferencia entre los selectores queryBy y getBy es que getBy lanza un error si el elemento DOM no existe, mientras que queryBy devuelve undefined si el elemento no existe.

El test también muestra cómo se pueden usar los selectores findBy. Estos selectores se pueden comparar con las los selectores queryBy, pero son asincrónicas. Podemos usarlos para esperar hasta que se agregue un elemento al documento.

Para hacer que nuestros tests sean resistentes a los pequeños detalles, prefiero usar los selectores findBy en lugar de las getByQuery.

El test sigue siendo fácil de leer después de estos cambios, así que continuemos con el siguiente paso.

Digamos que, por razones de rendimiento, hemos modificado la búsqueda interna y se agregó un retraso a la búsqueda. En el peor de los casos, cuando el retraso es alto, lo más probable es el test existente falle debido a un tiempo de espera. Pero incluso si el retraso fue lo suficientemente bajo como para no causar un tiempo de espera, el test tarda más en ejecutarse.

Como remedio, tenemos que introducir cronómetros falsos en el test para que el tiempo pase más rápido. Es un poco más avanzado, pero sin duda es una buena herramienta. Al principio, esto fue complicado para mí, pero una vez que me acostumbré, comencé a apreciar este concepto cada vez más. También empiezas a sentirte como un mago del tiempo, lo cual es una gran sensación.

El test a continuación usa los timers falsos de Jest, pero también puede usar los métodos de utilidad fakeAsync y tick de @angular/core/testing.

it('renders the table', async () => {
    jest.useFakeTimers();

    await render(EntitiesComponent, {
        declarations: [TableComponent],
        providers: [
            {
            provide: EntitiesService,
            useValue: {
                fetchAll: jest.fn().mockReturnValue(
                of([...]),
                ),
            },
            },
        ],
    });

    expect(
        await screen.findByRole('heading', { name: /Entities Title/i })
    ).toBeInTheDocument();

    expect(
        await screen.findByRole('cell', { name: /Entity 1/i })
    ).toBeInTheDocument();
    expect(
        await screen.findByRole('cell', { name: /Entity 2/i })
    ).toBeInTheDocument();
    expect(
        await screen.findByRole('cell', { name: /Entity 3/i })
    ).toBeInTheDocument();

    userEvent.type(
        await screen.findByRole('textbox', { name: /Search entities/i }),
        'Entity 2'
    );

    // jest.advanceTimersByTime(DEBOUNCE_TIME);
    // esto es mejor, ya que el test pasara si el debouce time se incrementa.
    jest.runOnlyPendingTimers();

    await waitForElementToBeRemoved(
        () => screen.queryByRole('cell', { name: /Entity 1/i })
    );
    expect(
        await screen.findByRole('cell', { name: /Entity 2/i })
    ).toBeInTheDocument();
});

En la última adición al componente, estamos agregando dos botones. Un botón para crear una nueva entidad y el segundo botón para editar una entidad existente. Ambas acciones dan como resultado que se abra un modal. Debido a que estamos probando el componente de entidades, no nos importa la implementación del modal, es por eso que mockea el modal en el test. Recordar que el modal se le realiza un test por separado.

El siguiente test confirma que el servicio modal se invoca cuando un usuario hace clic en estos botones.

import {
    render,
    screen,
    waitForElementToBeRemoved,
    within,
    waitFor,
} from '@testing-library/angular';
import { provideMock } from '@testing-library/angular/jest-utils';
import userEvent from '@testing-library/user-event';

it('renders the table', async () => {
    jest.useFakeTimers();

    await render(EntitiesComponent, {
        declarations: [TableComponent],
        providers: [
            {
                provide: EntitiesService,
                useValue: {
                    fetchAll: jest.fn().mockReturnValue(of(entities)),
                },
            },
            provideMock(ModalService),
        ],
    });
    const modalMock = TestBed.inject(ModalService);

    expect(
        await screen.findByRole('heading', { name: /Entities Title/i })
    ).toBeInTheDocument();

    expect(
        await screen.findByRole('cell', { name: /Entity 1/i })
    ).toBeInTheDocument();
    expect(
        await screen.findByRole('cell', { name: /Entity 2/i })
    ).toBeInTheDocument();
    expect(
        await screen.findByRole('cell', { name: /Entity 3/i })
    ).toBeInTheDocument();

    userEvent.type(
        await screen.findByRole('textbox', { name: /Search entities/i }),
        'Entity 2'
    );

    jest.advanceTimersByTime(DEBOUNCE_TIME);

    await waitForElementToBeRemoved(
        () => screen.queryByRole('cell', { name: /Entity 1/i })
    );
    expect(
        await screen.findByRole('cell', { name: /Entity 2/i })
    ).toBeInTheDocument();

    userEvent.click(
        await screen.findByRole('button', { name: /New Entity/i })
    );
    expect(modalMock.open).toHaveBeenCalledWith('new entity');

    const row = await screen.findByRole('row', {
        name: /Entity 2/i,
    });
    userEvent.click(
        await within(row).findByRole('button', {
            name: /edit/i,
        }),
    );
    // to have an example, let's say that there's a delay before the modal is opened
    waitFor(() =>
        expect(modalMock.open).toHaveBeenCalledWith('edit entity', 'Entity 2')
    );
});

Vemos muchas cosas nuevas en este test, echemos un vistazo más de cerca.

Hacer clic en el botón "new entity" no es nada interesante, y ya deberíamos haber sabido cómo hacerlo. Usamos el método userEvent.click para simular un clic del usuario en el botón. A continuación, verificamos que el servicio modal se haya invocado con los argumentos correctos.

Si observamos de cerca la configuración del test, notamos que provideMock se usa desde @testing-library/angular/jest-utils para simular un ModalService.provideMock envuelve todos los métodos del servicio provisto con una implementación simulada del mock. Esto hace que sea rápido y fácil afirmar si se ha llamado a un método.

Es una historia diferente para el botón "edit entity", donde podemos ver dos nuevos métodos, within y waitFor.

El método within se usa porque hay un botón de edición para cada fila de la tabla. Dentro podemos especificar en qué botón de edición queremos hacer clic, en el test anterior es el botón de edición que corresponde a la "Entity 2".

El segundo método, waitFor, se usa para esperar hasta que la afirmación dentro de su devolución de llamada sea exitosa. En este ejemplo, el componente usa un retraso entre el evento de clic del botón de edición antes de abrir el modal (solo para tener un ejemplo donde se puede usar waitFor). Con waitFor podemos esperar hasta que eso suceda.

EJEMPLOS ADICIONALES

DIRECTIVAS

Hasta ahora, solo hemos cubierto los tests de componentes. Afortunadamente, no hay muchas diferencias al probar las directivas. La única diferencia es que tenemos que proporcionar una plantilla para el método render. Si prefiere esta sintaxis, también puede usarla para representar un componente.

El resto del test sigue siendo la misma. El test usa el objeto de screen y los métodos de utilidad para afirmar que la directiva hace lo que se supone que debe hacer.

Por ejemplo, el siguiente test renderiza la directiva appSpoiler que oculta el contenido del texto hasta que se hace hover en el elemento.

test('it is possible to test directives', async () => {
    await render('<div appSpoiler data-testid="sut"></div>', {
        declarations: [SpoilerDirective],
    });

    const directive = screen.getByTestId('sut');

    expect(screen.queryByText('I am visible now...')).not.toBeInTheDocument();
    expect(screen.queryByText('SPOILER')).toBeInTheDocument();

    fireEvent.mouseOver(directive);
    expect(screen.queryByText('SPOILER')).not.toBeInTheDocument();
    expect(screen.queryByText('I am visible now...')).toBeInTheDocument();

    fireEvent.mouseLeave(directive);
    expect(screen.queryByText('SPOILER')).toBeInTheDocument();
    expect(screen.queryByText('I am visible now...')).not.toBeInTheDocument();
});

NGRX STORE

Nos tomó un tiempo hacer tests de componentes "correctos" que tienen una interacción con la NgRx Store. este finalmente se hace con al hacer click, para llamar el MockStore.

La primera versión de nuestros tests no se hacía mock NgRx Store y usaba toda la infraestructura NgRx (reducers, selectors, effects). Si bien esta configuración estaba probando todo el flujo, también significaba que el Store debía inicializarse para cada test. Al comienzo del proyecto, esto era factible, pero rápidamente creció hasta convertirse en un desastre inmanejable.

Como solución, los desarrolladores estaban recurriendo a wrapper de servicios alrededor de Store (un facade). Pero reescribir la lógica de su aplicación, solo para el test, no es una buena práctica.

Ahora, con MockStore tenemos lo mejor de ambos mundos. El test se centra en el componente y los detalles de NgRx Store se eliminan del test.

En el próximo test, veremos cómo usar MockStore en un test de componentes. Utiliza el mismo componente de ejemplo que tests anteriores, pero reemplaza el servicio de entidades y el servicio modal con NgRx Store.

Para crear el store se utiliza el método provideMockStore, en el que podemos sobrescribir los resultados de los selectores que se utilizan dentro del componente. Podemos asignar un mock al método dispatch para verificar que se envían las acciones. Cuando sea necesario, también puede actualizar el resultado del selector.

import { render, screen } from '@testing-library/angular';
import { MockStore, provideMockStore } from '@ngrx/store/testing';

it('renders the table', async () => {
    await render(EntitiesComponent, {
        declarations: [TableComponent],
        providers: [
            provideMockStore({
                selectors: [
                    {
                        selector: fromEntities.selectEntities,
                        value: [...],
                    },
                ],
            }),
        ],
    });

    // crea el mock del `dispatch`
    // este mock se ultilza para verificar las acciones hicieron dispatch
    const store = TestBed.inject(MockStore);
    store.dispatch = jest.fn();
    expect(store.dispatch).toHaveBeenCalledWith(fromEntities.newEntityClick());

    // esto provee un resultaod nuevo del selector.
    fromEntities.selectEntities.setResult([...]);
    store.refreshState();
});

CONCLUSIÓN

Debido a que los tests están escritas desde la perspectiva del usuario, son mucho más legibles y fáciles de entender.

Desde mi experiencia, siguiendo esta práctica, los tests son más robustas para cambios futuros. Un test es frágil cuando se prueba la implementación interna del componente, ejemplo: Cuando y cuándo se invocan los métodos (ciclo de vida).

Los cambios a los tests completos ocurren con menos frecuencia porque esto significaría que la interfaz de usuario del componente habría cambiado drásticamente. Estos cambios también son visibles para un usuario final. En ese momento, probablemente sea mejor escribir un nuevo componente y escribir un test nuevo, en lugar de intentar modificar el componente existente y los casos de prueba.

La única razón por la que tendría que cambiar un test después de una refactorización es cuando el componente se divide en varios componentes. En este caso, debe agregar todos los componentes/módulos/servicios nuevos a los tests afectados, pero el resto del test permanece igual (si la refactorización fue exitosa, de lo contrario, ¿puede incluso llamarse refactorización?). Incluso estos cambios pueden quedar obsoletos si está utilizando el patrón de módulos angulares de un solo componente (SCAM). Para una mirada detallada y los beneficios, lea Test tolerantes al cambio usando SCAMSs

Es posible que también hayas notado que estoy escribiendo múltiples bloques de arrange/act/assert blocks en un solo test. Este es un hábito que aprendí de Kent C. Dodds, para obtener más detalles, le recomiendo el articulo "Escribiendo menos tests y más largos (version traducida)". Debido a que la inicialización al test también es costosa dentro de Angular, este hábito también acelera el tiempo de ejecución de su conjunto de tests.

Después de que nuestro equipo cambió a este enfoque de escribir tests, noté que los nuevos tests se escribían más rápido que antes. Sencillamente, porque acaba de hacer clic para escribir nuestros tests de esta manera. Me atrevo a decir que incluso trajo un poco de alegría mientras los escribía.

Quiero terminar esta publicación de blog con una cita de Sandi Metz, "Pruebe la interfaz, no la implementación".

Si quiere continuar mejorando sobre el testing en Angular, puedo recomendar los siguientes enlaces:

Angular Testing Library Repository Buenas prácticas con Angular Testing Library
Tests tolerantes al cambio en Angular usando SCAMs > Nota personal: Escribir este artículo me ayudo muchísimo a cambiar la forma escribir los tests, la verdad es un proceso que lleva tiempo y que recomiendo que integréis a todo el equipo, si te gusto el articulo no dudes compartirlo.

Photo by Laure Noverraz on Unsplash