Skip to main content

🧠 Menu ViewModel y Simulación de Datos (Mocks)

El archivo menu.viewmodel.ts (a través de la clase MenuViewModel) es el encargado de gestionar la obtención y el estado del menú de microfrontends en la aplicación.

Al invocar el método fetchMenu(loadMockdata = true), el sistema permite cargar datos simulados (mocks) para facilitar el desarrollo local y probar las conexiones con los remotos. Para ello, existen dos enfoques o propiedades de configuración en el ViewModel: mockData y mockDataConfig.

A continuación, se explica el uso y propósito de cada uno.

🔄 1. mockData (Versión Antigua)​

La propiedad mockData representa la versión antigua de cómo se configuraba el menú para apuntar a un entorno local.

En esta versión se definía de manera explícita y manual todo el árbol del menú de la aplicación.

Características principales:

  • Al usar mockData, prácticamente se sobrescribe toda la respuesta del backend y se sustituye por el objeto local estático.
  • Requiere codificar y mantener a mano cada ruta, módulo, ícono, roles y permisos (grants).
  • Desventaja: Resulta complejo de mantener en el tiempo, ya que si cambian los permisos o roles en base de datos, el mock manual quedará desactualizado y podría no reflejar el comportamiento real de UAT o PROD.

✨ 2. mockDataConfig (Versión Nueva y Óptima)​

La propiedad mockDataConfig es la versión nueva y recomendada por la arquitectura.

A diferencia del enfoque anterior, mockDataConfig usa como base la data real que se obtiene de la respuesta (response) y del token proveniente de los servicios (por ejemplo, desde UAT). La magia radica en que el sistema únicamente intercepta la URL original del entorno y la sustituye por el localhost, preservando intacta toda la demás configuración originaria (como roles, permisos, iconos, estructura, etc.).

🧩 Configuración por applicationName y remoteName​

En la sección del mfe dentro de mockDataConfig, el valor asignado corresponderá al nombre del proyecto que fue dado de alta en el parámetro applicationName.

Sin embargo, si un remoteEntry llegase a existir en otro proyecto que no es el suyo (es decir, estás probando un remoto expuesto que se aloja sobre otro MFE diferente), se debe tener una configuración doble:

  1. Una apuntando al mfe del applicationName.
  2. Otra apuntando al remoteName del sub-ítem correspondiente.

Ejemplo de configuración:

private mockDataConfig: { url: string; mfe: string | undefined }[] = [
  {
    url: 'http://localhost:4204/remoteEntry.js',
    mfe: 'arch-views-mfe', // Esto machea el applicationName
  },
  {
    url: 'http://localhost:4204/remoteEntry.js',
    mfe: 'alpura-mfe-arch-views', // Esto machea el remoteName del sub-ítem
  }
];

💡 Conclusión y Recomendación​

Cabe destacar que ambos mocks funcionan perfectamente y los desarrolladores tienen la total libertad de usar el que les convenga más al momento de configurar su entorno local.

No obstante, el enfoque más óptimo siempre será utilizar mockDataConfig. Al emplearlo, se garantiza que las pruebas locales de los microfrontends y sus componentes se rijan bajo las configuraciones de seguridad (roles, permisos) más fidedignas posibles.