Saltar al contenido principal

Exposición e incrustación con el SDK de microfrontend

El primer paso en este proceso es crear una nueva aplicación de Jutro y, luego, adaptarla como microfrontend. Luego, se consume este nuevo microfrontend dentro de otra aplicación de Jutro. En nuestro ejemplo, creamos una segunda aplicación de Jutro con Jutro CLI que luego consume el microfrontend recién creado.

Paso 1: Instalar el paquete de microfrontends​

Cree una instancia de nueva aplicación de Jutro o cambie una aplicación basada en Jutro existente para que sea la microaplicación que se está incrustando.

En su aplicación basada en Jutro, instale el paquete @jutro/micro-frontends de modo que tenga acceso a la funcionalidad de microfrontend:

npm i --save @jutro/micro-frontends@<your-jutro-version>

No olvide que versión del paquete debe coincidir con los otros paquetes de Jutro Design System, como @jutro/components.

Note:

La dependencia @jutro/auth ahora es opcional para los paquetes @jutro/router y @jutro/components . Sin embargo, el componente @jutro/micro-frontends package requiere que se agregue @jutro/auth a las dependencias de la aplicación que se van a utilizar.

Paso 2: Exponer una aplicación de Jutro como microfrontend​

Una vez que haya instalado el paquete micro-frontend, siga estos pasos para convertir la aplicación independiente en un microfrontend que puede incrustar en una aplicación shell. A pesar de haberse convertido en un microfrontend, la aplicación sigue funcionando en modo independiente.

  1. En el repositorio del microfrontend, asegúrese de que los archivos src/indexAsync.js y src/startApp.js estén presentes y no tengan conflictos de Git. Si los archivos no están presentes, créelos manualmente. Agregue lo siguiente a src/indexAsync.js:

    src/indexAsync.js
    import('./startApp').then(({ startApp }) => startApp());
  2. En src/startApp.js, cambie la import de la función start a @jutro/micro-frontends.

    src/startApp.js
    // Replace the start function from @jutro/app
    import { start } from '@jutro/micro-frontends';
    import messages from './app/App.messages';
    /* ... */

    Debe llamar a la función de microfrontend start dentro de la función startApp:

    export const startApp = (mfeData) => {
    start(Jutro, {
    appName: messages.appName,
    appDescription: messages.appDescription,
    mfeData,
    });
    };
  3. Inicie su aplicación:

npm i
PORT=3001 npm run start

Paso 3: Incrustar un microfrontend en una aplicación shell​

El SDK de microfrontend le permite incrustar su microfrontend en cualquier aplicación web. No es necesario que la aplicación shell sea una aplicación de Jutro. Ni siquiera hace falta que sea una aplicación de React. La única condición que debe cumplir es que se debe exponer como un microfrontend. Las aplicaciones de iframe respetan las propiedades pasadas desde sus aplicaciones shell cuando se trata del comportamiento de Jutro.

Luego, puede incrustarlo siguiendo este ejemplo:

<script src="http://your-app.com/sub-path/jutro-micro-frontends.js"></script>
<script>
const selector = document.getElementById('micro-app-container');
const renderer = JutroMicroFrontends.createRoot(
selector,
'claimMicroFrontend@http://your-app.com'
);
renderer.render(appSettings);
// appSettings: see example below for details
</script>
Note: Para el script src, https://your-app.com/sub-path es la URL en la que se implementa su microfrontend. Debería poder verlo en la URL que especifique; sin embargo, se renderizaría en modo independiente, sin ninguna aplicación shell a su alrededor.
Note: El ID de la aplicación (por ejemplo, claimMicroFrontend en 'claimMicroFrontend@http://your-app.com') identifica de forma única su microfrontend para la aplicación shell. Para obtener más información sobre cómo configurar el ID de la aplicación, consulte Configuración del ID de aplicación de su microfrontend.

Especifique el microfrontend que desea incrustar como se muestra en la primera línea del ejemplo. El <script /> entonces crea una propiedad de objeto de ventana window.JutroMicroFrontends. Actualmente, esta es la única forma de utilizar el SDK de microfrontend. El SDK también tiene la limitación de un solo microfrontend incrustado a la vez.

integrateJutro permite habilitar y deshabilitar varias integraciones. Esta propiedad, al igual que el resto de las opciones de integración, se establece en false. Encontrará más información acerca de todas las propiedades disponibles en la sección sobre referencia de la API de microfrontend.

Tenga en cuenta que la autenticación no se maneja automáticamente cuando se utiliza el SDK de microfrontend. Para obtener más información, consulte la sección autenticación.

Pasaje de propiedades​

Cuando utilice el SDK de microfrontend, pase las propiedades personalizadas como pares clave-valor a la función render().

renderer.render({
sampleProp: 'sample prop text',
anotherCustomProp: true,
jutro: {
// ...Jutro settings
},
// ...more app settings
});

Las propiedades personalizadas se pasan al componente <AppRoot> en el microfrontend.

App.js
export const AppRoot = ({ sampleProp, anotherCustomProp, ...otherProps }) => {
// your implementation
};

export const Jutro = (props) => (
<SettingsProvider>
<AppRoot {...props} />
</SettingsProvider>
);

Autenticación​

Para habilitar la integración de autenticación, configure la propiedad integrateAuth en true. Esta integración está habilitada de forma predeterminada.

Para hacer que las aplicaciones comuniquen información de autenticación, debe pasar tokens de autenticación mediante la propiedad auth. Esta acepta los siguientes argumentos:

  • accessToken: jutro.auth.accessToken. String
  • idToken: auth?.idToken. String
  • userInfo: auth.userInfo - OidcUserInfo | null. Cuando se habilita la integración de autenticación, este parámetro es obligatorio.
{
jutro: {
integrateAuth: true;
auth: {
accessToken: 'access-token',
idToken: 'id-token',
userInfo: {
...
name: 'name',
email: 'mymail@mail.com'
...
}
}
}
}

La aplicación shell es responsable de actualizar los tokens. Los tokens deben actualizarse antes de que caduquen para no interrumpir el trabajo del usuario. El cliente de autenticación de Jutro lo hace automáticamente.

Requisitos​

Para garantizar el correcto funcionamiento al incrustar un microfrontend con la integración de autenticación habilitada, existen requisitos específicos relacionados con la comunicación segura y los service workers. Un service worker es un script en segundo plano que se ejecuta en el navegador y administra tareas como el manejo de flujos de autenticación.

Para el desarrollo, se puede usar localhost con HTTP, y para la producción, se deben usar implementaciones con HTTPS. Estas configuraciones garantizan que los service workers funcionen correctamente al manejar los flujos de autenticación. Si el microfrontend utiliza el service worker, el shell y el microfrontend deben implementarse en el mismo sitio.

Las siguientes configuraciones se consideran seguras y permiten que el service worker funcione correctamente:

  • http://localhost: localhost en HTTP se trata como seguro, una excepción a las políticas de seguridad típicas.
  • https://example.com/app: URL HTTPS totalmente válida.
  • https://localhost: Funciona con un certificado de confianza autofirmado.
  • https://127.0.0.1: También requiere un certificado de confianza autofirmado.

En los casos en los que utilice un shell localhost, asegúrese de que el microfrontend implementado incluya la directiva frame-ancestors adecuada en su encabezado de Política de seguridad de contenido (CSP) para permitir la incrustación.

En el caso de las configuraciones HTTPS localhost sin un certificado válido, los service workers no funcionan, por ello, Jutro utiliza el almacenamiento de sesión para el manejo de la autenticación. De forma predeterminada, Jutro deshabilita el service worker y utiliza el almacenamiento de sesión para localhost con aplicaciones HTTPS. En estos casos, muestra la siguiente advertencia: el service worker @jutro/auth solo se puede registrar para orígenes seguros. Está ejecutando un servidor https local, por lo tanto, el almacenamiento de la sesión se utiliza como respaldo. Si desea probar el service worker en la configuración local de https, debe habilitarlo explícitamente agregando la variable .env REACT_APP_JUTRO_AUTH_HTTPS_LOCALHOST_SERVICE_WORKER=true o cambiando a HTTP simple.

Ciertas configuraciones impiden que los service workers se registren, lo que puede interrumpir los flujos de autenticación. El efecto depende de cómo interactúa el microfrontend con la aplicación shell. Si el microfrontend obtiene sus tokens del shell y el shell tiene habilitada la autenticación, por ejemplo, utiliza un service worker; solo el shell debe cumplir con los requisitos del service worker. El microfrontend no utiliza el service worker y no necesita cumplir con estos requisitos. Si el microfrontend no obtiene sus tokens del shell, independientemente de si el shell tiene la autenticación habilitada o no, el microfrontend debe utilizar un service worker. En este caso, tanto el microfrontend como el shell deben cumplir con los requisitos del service worker para garantizar el correcto funcionamiento de los flujos de autenticación.

Los service workers no se pueden registrar si el shell o el microfrontend funcionan en una de las siguientes condiciones, lo que interrumpirá los flujos de autenticación:

  • http://127.0.0.1. No se considera un contexto seguro.
  • http://example.com/app. Conexión HTTP no segura.
  • https://localhost. Sin certificado de confianza.
  • https://example.com/app. Si el certificado no es válido.

Compatibilidad de versiones​

Las aplicaciones shell más antiguas que utilizan Jutro pero anteriores a Jutro 8, donde el componente MicroFrontend (MicroApp en versiones anteriores de Jutro) se mejoró para admitir el modo aislado, aún pueden usar la biblioteca auxiliar para importar aplicaciones iframe modernas con cualquier versión. Tenga en cuenta que habrá más pasos para integrar las características y el estado compartido de Jutro.

Casos de uso​

Globalización​

La propiedad g11n le permite escuchar los cambios de globalización en la aplicación iframe y reaccionar a ellos manteniendo sincronizada la aplicación shell. La integración de la globalización requiere la implementación en el lado del shell. En el siguiente ejemplo, se muestra la estructura de la configuración de localización:

{
availableLanguages?: Array<string>;
availableLocales?: Array<string>;
defaultCountryCode?: string;
defaultCurrency?: string;
defaultTimeZone?: string;
preferredLanguage?: string;
preferredLocale?: string;
onGlobalizationChange(changeObject)
};

La devolución de llamada onGlobalizationChange se ejecuta cuando un microfrontend cambia su configuración regional o idioma. changeObject acepta los siguientes valores:

  • language?: string
  • languageChanged?: boolean
  • locale: string
  • localeChanged: boolean

En el siguiente ejemplo, se muestra cómo configurar la globalización y manejar los cambios de idioma y configuración regional en un microfrontend:

const { language, languageOnChangeCallback } = useLanguage();
const { locale, localeOnChangeCallback } = useLocale();

const renderMfe = (route, otherProps) => {
root?.render({
...otherProps,
jutro: {
g11n: {
preferredLocale: 'en-EN',
preferredLanguage: 'en-EN',
defaultCountryCode: 'US',
defaultCurrency: 'USD',
defaultTimezone: 'GMT',
onGlobalizationChange(change) {
if (change.languageChanged && change.language) {
languageOnChangeCallback?.(change.language);
}

if (change.localeChanged && change.locale) {
localeOnChangeCallback?.(change.locale);
}
},
},
},
});
};

configOverrides.localeSettings invalida los valores especificados en la propiedad g11n. No se recomienda usarlo cuando la aplicación con SDK proporciona una integración personalizada con g11n.

Invalidaciones de Jutro​

configOverrides de Jutro sigue siendo compatible y se puede pasar con normalidad:

jutro: {
configOverrides: {
// Jutro config overrides, if any
},
}

Integración de modal​

Los modales también se pueden integrar para que cubran la pantalla fuera del cuadro de iframe. Para ello, pase las funciones modales admitidas desde la aplicación shell:

jutro: {
modal: {
showAlert: ({
status,
icon,
title,
message,
confirmButtonText,
}) => {
console.log({
status,
icon,
title,
message,
confirmButtonText,
});
},
showConfirm: ({
status,
icon,
title,
message,
confirmButtonText,
cancelButtonText,
}) => {
const testResult =
document.getElementById('callbackResult');
testResult.innerText = message;
},
},
...
}

El Microfrontend SDK carece de la capacidad para mostrar la interfaz de usuario dentro del contexto de la aplicación shell. Para mostrar un modal dentro de la aplicación shell, integre el modal directamente con el resto de la aplicación shell. El Microfrontend SDK no puede controlar las características de la aplicación shell, como el estilo, el árbol de accesibilidad o los agentes de escucha de eventos.

A diferencia del componente MicroFrontend, que se integra a la perfección con las aplicaciones de Jutro basadas en React para manejar los modales, el iframe del microfrontend SDK de Jutro funciona independientemente de estas integraciones. No es posible enviar elementos de React personalizados, por lo tanto, la integración de modal se limita a las funciones modales que usan parámetros serializables.

Si los modales se basan en traducciones de strings disponibles solo en la aplicación iframe, la traducción debe ocurrir antes de llamar a las funciones modales. El Microfrontend SDK no incluye capacidades de traducción de mensajes. Al pasar un objeto de mensaje como showAlert({ id: "my-message", defaultMessage: "Some text" }), la aplicación shell recibe un objeto de mensaje no traducido:


render({ jutro: {
modal: {
showAlert: (message) => // receives untranslated message object
}
}});

Para mostrar el texto correcto en el modal, realice la traducción en el lado del shell utilizando las herramientas de traducción disponibles o complete la traducción en el microfrontend antes de invocar el modal.

Por lo general, si incrusta un iframe en una página, al actualizar la página se vuelve a cargar la aplicación iframe. Como resultado, la aplicación iframe pierde su estado. El Microfrontend SDK de Jutro resolvió este problema, ya que permite que la aplicación shell y solo la aplicación shell sea la única fuente de información para el enrutamiento. Esto le permite a usted administrar las rutas y el historial y, al mismo tiempo, conservar el estado de cualquier ubicación en la aplicación, incluidas las ubicaciones renderizadas por la aplicación iframe.

Dado que su aplicación shell puede ser cualquier tipo de aplicación web y no necesariamente una aplicación de Jutro, puede usar cualquier biblioteca de enrutamiento que desee. La aplicación iframe puede escuchar los cambios de navegación en la aplicación shell y actualizar su ubicación e historial gracias a la propiedad router.

La propiedad router se define de la siguiente manera:

export type RouterIntegrationProps = {
location?: string;
onLocationChange?: (
pathname: string,
action: 'PUSH' | 'REPLACE' | 'GO'
state?: unknown,
) => void;
state?: unknown;
};
  • location: La ubicación deseada, con respecto a la aplicación shell.
  • onLocationChange: Una devolución de llamada opcional que desencadena el microfrontend incrustado cuando el usuario navega o es redirigido. Solo es obligatoria cuando el shell necesita manejar cambios de ruta. La devolución de llamada onLocationChange recibe los siguientes argumentos:
    • pathname: La nueva ubicación en la que el microfrontend quiere estar. Es relativa al lugar en el que se incrusta el microfrontend en la aplicación shell.
    • action: La acción que activó el cambio de navegación.
    • state: El objeto de estado asociado con la nueva ubicación. Para obtener más información, consulte la documentación de MDN sobre pushState().
  • onBlockChange: Permite utilizar la API history.block, que puede impedir que los usuarios salgan de la página actual, por ejemplo, cuando tienen algunos datos sin guardar. Se llama a la devolución de llamada onBlockChange con isBlocked=true y una devolución de llamada de aviso opcional cuando el microfrontend quiere bloquear la navegación. Se la puede llamar con isBlocked=false cuando se elimina el bloqueo después de llamar a unblock en el microfrontend. Acepta los siguientes argumentos:
    • isBlocked: Booleano
    • prompt: Indicación opcional

El argumento action puede ser uno de los siguientes:

  • PUSH: el usuario ha navegado a una nueva ubicación.
  • REPLACE: el usuario navegó a una nueva ubicación, lo que reemplaza la ubicación actual en el historial.
  • GO: el usuario ha navegado hacia atrás o hacia delante, la ubicación será un número que indica cuántos pasos retrocedió o avanzó. Por ejemplo, -3 significa que retrocedemos 3 pasos en el historial.

El argumento state solo es útil cuando action es PUSH o REPLACE.

A continuación, se muestra un ejemplo en el que estamos creando una aplicación shell que tiene una ruta /claims y queremos incrustar la aplicación de microfrontend en esta ruta. Dentro de este microfrontend hipotético, tenemos las siguientes rutas:

  • /: la lista de todos los siniestros.
  • /new: el formulario para crear un nuevo siniestro.
  • /:claimId/edit: el formulario para editar un siniestro existente.

La devolución de llamada onLocationChange se puede utilizar para actualizar la ubicación y el historial de la aplicación shell cuando el microfrontend navega a través de ella.

Por ejemplo, si el usuario navega a /claims/new en la aplicación shell, la aplicación iframe puede actualizar su ubicación a /new y enviarla al historial del microfrontend. Luego, el microfrontend puede utilizar su historial para navegar hacia atrás y hacia adelante.

En el siguiente fragmento de código, se muestra cómo el microfrontend puede escuchar los cambios de navegación en la aplicación shell y actualizar su ubicación e historial según corresponda. Estamos usando la API del navegador sin ninguna biblioteca para simplificar el ejemplo, pero puede usar la biblioteca que desee para administrar el historial del microfrontend.

// The routes in question are:
// /claims/
// /claims/new
// /claims/:claimId/edit
// ^ base location for the iframe app
const microFrontendPathname = '/claims';
const relativeLocation = document.location.href
.replace(window.location.origin, '')
.replace(microFrontendPathname, '');
// after we remove the origin and the base location, we get the relative location
// relativeLocation equals '/', or '/new', or '/:claimId/edit'

const jutro = {
router: {
location: '/mfe/location',
// you can use location to pass queryParams:
// location: '/route?paramA=value1&paramB=value2',
onLocationChange: (location, action, state) => {
// location equals '/'
// location equals '/new'
// location equals '/:claimId/edit'

if (action === 'GO') {
// The user navigated back or forward
// location is the number of steps to go back or forward
// for example, -3 means we are going back 3 steps in the history
history.go(location);
return;
}

if (action === 'PUSH') {
// The user navigated to a new location, pushing a new entry in the browser history
history.pushState(state, '', `${microFrontendPathname}${location}`);
return;
}

if (action === 'REPLACE') {
// The user was redirected, replacing the entry in browser history,
// so pressing the back button will not go back to the previous location
history.replaceState(state, '', `${microFrontendPathname}${location}`);
return;
}
},
},
};

Si desactiva la integración del enrutador mediante la propiedad integrateRouter: false, la barra de ubicación del navegador no cambia y el historial del shell no se actualiza, ya que no está escuchando las actualizaciones del microfrontend.

Tematización​

La aplicación shell puede determinar la tematización de Jutro mediante el paso de las propiedades themeConfig, y la aplicación shell también puede escuchar los cambios internos del tema.

jutro: {
theme: {
themeConfig: {
// All the theme configs accepted by Jutro, determines the theme used by the
// iframe app on startup. Check the Jutro theming props for more details.
// For example, if you want to use a Jutro provided theme, you can base your
// config on it and pass 'themeConfig' as follows:
// name: 'Customer',
// baseTheme: 'Customer'
},
switchTheme: newThemeConfig => {
// A callback that will be triggered when the iframe app switches its theme.
// Use it to change the shell app state accordingly, if desired
},
},
}

Notificaciones del sistema​

También se pueden integrar notificaciones del sistema para que se muestren fuera del cuadro de iframe. Para ello, pase la devolución de llamada del desencadenador toast desde la aplicación shell:

jutro: {
toast: {
toast: ({ message, type, autoClose, autoFocus, linkProps }) => {
// Use the callback to render a toast in the shell app leveraging all the
// Jutro props for toasts
},
},
}

Una limitación aquí es que, en caso de que estas notificaciones del sistema se basen en traducciones de string solo disponibles en la aplicación iframe, la traducción del string debe ocurrir antes de llamar a ToastProvider. El valor final debe pasarse a la notificación del sistema, de lo contrario, el proveedor de la aplicación shell no tendrá las traducciones necesarias.

Cómo mostrar un encabezado o pie de página dentro del microfrontend​

jutro: {
modal: {
showAlert: ({
status,
icon,
title,
message,
confirmButtonText,
}) => {
console.log({
status,
icon,
title,
message,
confirmButtonText,
});
},
showConfirm: ({
status,
icon,
title,
message,
confirmButtonText,
cancelButtonText,
}) => {
const testResult =
document.getElementById('callbackResult');
testResult.innerText = message;
},
},
...
}

El Microfrontend SDK carece de la capacidad para mostrar la interfaz de usuario dentro del contexto de la aplicación shell. Para mostrar un modal dentro de la aplicación shell, integre el modal directamente con el resto de la aplicación shell. El Microfrontend SDK no puede controlar las características de la aplicación shell, como el estilo, el árbol de accesibilidad o los agentes de escucha de eventos.

A diferencia del componente microfrontend, que se integra a la perfección con las aplicaciones de Jutro basadas en React para manejar los modales, el iframe del SDK de microfrontend de Jutro funciona independientemente de estas integraciones. No es posible enviar elementos de React personalizados, por lo tanto, la integración de modal se limita a las funciones modales que usan parámetros serializables.

Si los modales se basan en traducciones de strings disponibles solo en la aplicación iframe, la traducción debe ocurrir antes de llamar a las funciones modales. El Microfrontend SDK no incluye capacidades de traducción de mensajes. Al pasar un objeto de mensaje como showAlert({ id: "my-message", defaultMessage: "Some text" }), la aplicación shell recibe un objeto de mensaje no traducido:


render({ jutro: {
modal: {
showAlert: (message) => // receives untranslated message object
}
}});

Para mostrar el texto correcto en el modal, realice la traducción en el lado del shell utilizando las herramientas de traducción disponibles o complete la traducción en el microfrontend antes de invocar el modal.

Globalización​

La propiedad g11n le permite escuchar los cambios de globalización en la aplicación iframe y reaccionar a ellos manteniendo sincronizada la aplicación shell. La integración de la globalización requiere la implementación en el lado del shell. En el siguiente ejemplo, se muestra la estructura de la configuración de localización:

{
availableLanguages?: Array<string>;
availableLocales?: Array<string>;
defaultCountryCode?: string;
defaultCurrency?: string;
defaultTimeZone?: string;
preferredLanguage?: string;
preferredLocale?: string;
onGlobalizationChange(changeObject)
};

La devolución de llamada onGlobalizationChange se ejecuta cuando un microfrontend cambia su configuración regional o idioma. changeObject acepta los siguientes valores:

  • language?: string
  • languageChanged?: boolean
  • locale: string
  • localeChanged: boolean

En el siguiente ejemplo, se muestra cómo configurar la globalización y manejar los cambios de idioma y configuración regional en un microfrontend:

const { language, languageOnChangeCallback } = useLanguage();
const { locale, localeOnChangeCallback } = useLocale();

const renderMfe = (route, otherProps) => {
root?.render({
...otherProps,
jutro: {
g11n: {
preferredLocale: 'en-EN',
preferredLanguage: 'en-EN',
defaultCountryCode: 'US',
defaultCurrency: 'USD',
defaultTimezone: 'GMT',
onGlobalizationChange(change) {
if (change.languageChanged && change.language) {
languageOnChangeCallback?.(change.language);
}

if (change.localeChanged && change.locale) {
localeOnChangeCallback?.(change.locale);
}
},
},
},
});
};

configOverrides.localeSettings invalida los valores especificados en la propiedad g11n. No se recomienda usarlo cuando la aplicación con SDK proporciona una integración personalizada con g11n.

Invalidaciones de Jutro​

configOverrides de Jutro sigue siendo compatible y se puede pasar con normalidad:

jutro: {
configOverrides: {
// Jutro config overrides, if any
},
}

Atributos de iframe​

Es posible pasar atributos adicionales para microfrontends incrustados mediante el modo aislado o el SDK. Esto permite habilitar varias características del navegador. Las entradas de la propiedad iframeAttributes se agregan al elemento HTML iframe. Solo se permiten las propiedades allow, referrerpolicy y sandbox. Puede obtener más información acerca de estas propiedades en la guía de referencia de la API de microfrontend.

renderer.render({
sampleProp: 'sample prop text',
anotherCustomProp: true,
jutro: {
iframeAttributes: {
allow: 'geolocation; camera "none"',
referrerpolicy: 'noreferrer',
sandbox: 'allow-scripts',
},
},
});

Cambio de tamaño​

Las aplicaciones iframe de Jutro utilizan la biblioteca iframe-resizer para manejar el cambio de tamaño automático del iframe según el contenido dentro de la aplicación iframe.

Para que el cambio de tamaño automático funcione, el iframe debe colocarse dentro de un contenedor con una dimensión relativa, como porcentaje o ancho de ventana gráfica (viewport width, vw). Las aplicaciones de Jutro están diseñadas para manejar el estilo móvil, por lo general, sin anchos mínimos; por eso, el uso de un ancho relativo suele ser el camino a seguir aquí.

// using the iframe app helper library
<div
style={{ width: '100%' }}
id="myDiv"
/>

Si el estilo de la página de la aplicación shell no restringe el contenedor, puede no establecer el ancho. El contenedor y su iframe se expandirán para ocupar todo el ancho disponible.

Note: Si su microfrontend no cambia de tamaño correctamente dentro de la aplicación shell, debe agregar la siguiente importación en el código de su aplicación: import iframe-resizer/js/iframeResizer.contentWindow.

Volver a cargar un microfrontend​

Puede volver a cargar un microfrontend pasando la devolución de llamada () => window.location.reload() personalizada desde la aplicación shell. En el siguiente ejemplo, se muestra cómo implementarlo dentro de un botón:

const reloadMFE = () => {
window.location.reload();
};

return (
<div>
<button onClick={reloadMFE}>Reload Page</button>
</div>
);

Plano de planta de enrutamiento y microfrontends​

Si incrusta un microfrontend dentro de un plano de planta en una aplicación shell de Jutro con la integración de enrutamiento habilitada, tenga cuidado de no establecer exact en true. De lo contrario, una vez que el microfrontend navegue a /my-mfe/some-microfront-subpage, ya no coincidirá exactamente con /my-mfe y se desmontará.

{
/* ... omitted ... */
"floorplan.default": {
"routes": [
{
"title": {
"id": "id",
"defaultMessage": "My MicroFrontend"
},
"path": "/my-mfe",
"exact": false, // <-- Set this to false
"component": "MyMicroFrontend"
}
]
}
}

Unmounting a micro frontend​

To unmount a micro frontend, use the unmount() method to remove it from the DOM and free up resources. The following example shows how to use the unmount() method:


const mfeRoot = JutroMicroFrontends.createRoot(
selector,
'claimMicroFrontend@http://localhost:3000'
);

renderer.render({
{...}
});

renderer.unmount();

jutro.OnError property details​

The Microfrontend SDK onError property is an optional property added in Jutro 10.10 to add a callback invoked when an error occurs. This callback must adhere to the following type:

({ error: Error, errorInfo?:ErrorInfo }) => void
Note: Esto no está relacionado con la propiedad onError del elemento HTMLThis is unrelated to the onError prop from the HTML <iframe>.

Si se pasa una devolución de llamada a la propiedad OnError, se la llamará en dos situaciones:

  1. Si el microfrontend no se carga y han transcurrido los segundos de tiempo de espera. En este caso, el argumento errorInfo será undefined.
Note: Si no se pasa ninguna devolución de llamada a onError, se generará un error dentro de la función setTimeout(). Esto agregará un registro a la consola de DevTools, pero no se lo podrá detectar mediante un try/catch.

Si se pasa una devolución de llamada a onError, solo se llama a la devolución de llamada; no habrá mensajes de registro adicionales ni errores en setTimeout().

  1. Si el componente límite de error de nivel superior del microfrontend detecta un error. En este caso, el argumento errorInfo proviene de React y se documenta aquí en el punto de la viñeta info debajo de componentDidCatch(error, info).
Note: El límite de error de nivel superior es el componente que se pasa como propiedad errorBoundary a la función start(). Para obtener más información, consulte los documentos de configuración global.

Cuando se define la propiedad onError, se pasará como el valor de la propiedad onError al límite de error de nivel superior. Cuando se llama al límite de error de nivel superior onError, también llamará al onError del shell.

Si se utiliza el límite de error predeterminado, también conservará el comportamiento existente, como registrar el error en la consola y enviar eventos de análisis, si está configurado para hacerlo.

Si se usa un límite de error personalizado y no llama a onError cuando detecta un error, tampoco se llamará al onError del shell. En esta situación, solo se llamará al onError del shell cuando se agote el tiempo de espera del microfrontend.

Ejemplo completo​

Aplicación shell​

En este ejemplo, tenemos una aplicación shell que habilita la tematización, la navegación, la notificación del sistema y el modal:

<html>
<head>
<title>Non Jutro Shell</title>
</head>
<body>
<h1>SAMPLE PAGE TITLE</h1>
<div id="callbackResult"></div>
<div
id="micro-app-container"
style="width: 100vw"></div>
<script src="http://localhost:3001/jutro-micro-frontends.js"></script>
<script>
const selector = document.getElementById('micro-app-container');
const renderer = JutroMicroFrontends.createRoot(
selector,
'claimMicroFrontend@http://localhost:3001'
);
renderer.render(
{
sampleProp: 'sample prop text',
anotherCustomProp: true,
jutro: {
integrateJutro: true,
// theming
theme: {
themeConfig: {
name: 'Customer',
baseTheme: 'Customer',
},
},
// navigation
navigation: {
location: '/claims',
onLocationChange: (location, action, state) => {
const testResult = document.getElementById('callbackResult');
testResult.innerText = `Location: ${location}, Action: ${action}, State: ${state}`;
},
},
// toast
toast: {
toast: ({ message, type, autoClose, autoFocus, linkProps }) => {
const testResult = document.getElementById('callbackResult');
testResult.innerText = message;
},
},
// modal
modal: {
showAlert: ({
status,
icon,
title,
message,
confirmButtonText,
}) => {
alert(
JSON.stringify(
{
status,
icon,
title,
message,
confirmButtonText,
},
null,
2
)
);
},
showConfirm: ({
status,
icon,
title,
message,
confirmButtonText,
cancelButtonText,
}) => {
alert(`Message confirmed; STATUS: ${status}; "${message}"`);
},
},
onRender: () => {
console.log('onRender');
},
onLoadingFinished: () => {
console.log('onLoadingFinished');
},
configOverrides: {
customConfig: 'Micro-app overridden configuration',
localeSettings: {
availableLocales: ['en-US', 'es-ES'],
preferredLanguage: 'ES',
defaultCurrency: 'EUR',
},
},
appName: 'Micro-app overridden title',
},
},
{
// onLoaded is triggered when the browser calls the `load` event on the iframe that contains the micro frontend
onLoaded: () => {},
}
);
</script>
</body>
</html>