Saltar al contenido principal

Exposición e incrustación del componente MicroFrontend con aislamiento de contexto

Note: El uso del componente MicroFrontend con aislamiento de contexto se conocía anteriormente como modo iframe. Ahora se conoce como modo aislado. Todavía puede usar iframe como un valor para la propiedad mode en su código, pero ha quedado obsoleto. Se recomienda actualizar las referencias del modo iframe al modo isolated para evitar problemas futuros.

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>
Important: La 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. Create a file at root level (next to package.json) and name it overrides.config.js. Configure the micro frontend exposure in that file:

    module.exports = {
      webpack: {
        moduleFederation: {
          exposes: 'jutro-app',
          },
        },
      };
    • exposes - Specifies list of entries which should be exposed as federated modules. Refer to the official webpack module federation docs for more info.
    If you set exposes to the exact value jutro-app, it uses your entire app assuming the app is a standard Jutro app based on the template. This is the same as:
    exposes: {
      './startApp': './src/startApp',
        },
      filename: 'remoteEntry.[contenthash].js',
    You can provide your own config, if you are exposing to micro frontend in some other way. The string './startApp' cannot be changed to anything else. The MicroFrontend component in the shell app uses this name as a hardcoded value.
    {
              exposes: {
                './startApp': './src/paymentAppLauncher',
              },
              filename: 'secure.js',
            }

  4. Inicie su aplicación:

npm i
PORT=3001 npm run start

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

  1. Para cargar su microfrontend, utilice el componente MicroFrontend y configure la propiedad src. La propiedad src acepta el ID de aplicación de microfrontend junto con la URL de la aplicación. Para obtener más información sobre esta propiedad, consulte la página de referencia de la API de microfrontend.
Note: Para obtener más información sobre el ID de la aplicación de microfrontend, consulte Configuración del ID de la aplicación de su microfrontend.
import React from 'react';
import { MicroFrontend } from '@jutro/micro-frontends';

export const MyMicroFrontend = () => (
  <MicroFrontend
    jutro={{ mode: 'isolated' }}
    src="claimMicroFrontend@http://localhost:3001"
    exampleProp="Example prop"
    exampleCallback={() => console.log('Callback from shell')}
  />
);
Note: Los microfrontends se encapsulan automáticamente en los límites de error de Jutro, consulte la página Límite de error para obtener más información. También utilizan el componente cargador predeterminado.
  1. Inicie la aplicación shell:
npm i
PORT=3000 npm run start
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.

src​

Puede usar la función getMicroFrontendSrc con su propiedad src para obtener el origen desde la configuración. Esta función recupera el ID de aplicación y la URL de su microfrontend.

// import { MicroFrontend, getMicroFrontendSrc } from '@jutro/micro-frontends';
<MicroFrontend src={getMicroFrontendSrc('claimMicroFrontend')} />

Cuando haga esto, debe configurar microFrontendsConfig su src/config/config.json.

config.json
{
  "microFrontendsConfig": {
    "remotes": {
      "claimMicroFrontend": "claimMicroFrontend@http://localhost:3001"
    }
  }
}

Además, puede usar la propiedad src sin establecer el ID en la configuración. Simplemente pase un mfeAppId@uri. Tenga en cuenta que mfeAppId debe ser único. Se determina en la configuración del microfrontend.

Por ejemplo:

import React from 'react';
import { MicroFrontend } from '@jutro/micro-frontends';

export const MyMicroFrontend = () => (
  <MicroFrontend src="claimMicroFrontend@http://localhost:3001" />
  // or src="claimMicroFrontend@https://some-website.com"
);

Aplicación shell que pasa valores de configuración a microfrontend​

Los microfrontends no accederán a las configuraciones de aplicaciones shell ni las establecerán porque el almacenamiento de configuración de Jutro y las API del paquete @jutro/config en la aplicación shell y los microfrontends están aisladas entre sí.

Sin embargo, la aplicación shell aún puede proporcionar los valores iniciales para las configuraciones del microfrontend. La aplicación shell también puede invalidar los launchProps de Jutro pasados en la función start de Jutro. Para ello, utilice cualquiera de estas propiedades, o ambas, según sea necesario:

  • configOverrides: forma abreviada, en caso de que solo se necesite que las configuraciones de Jutro estén disponibles para la API getConfigValue.
Note: Estas propiedades están anidadas dentro de la propiedad jutro para separarlas de las propiedades que se pasarán a través del microfrontend.

Ejemplo de uso de las dos propiedades de invalidación de aplicaciones shell:

<MicroFrontend
  src={getMicroFrontendSrc('claimMicroFrontend')}
  jutro={{
    mode: 'isolated',
    router: {
      basename: '/welcome'
    },
    },
    configOverrides: {
      someConfig: 'Micro frontend config value',
    },
  }
/>

Ejemplo de cuando solo desea invalidar launchProps

<MicroFrontend
  src={getMicroFrontendSrc('claimMicroFrontend')}
  jutro={{
    mode: 'isolated',
    router: {
      basename: '/welcome'
    },
      config: [
        {
          someConfig: 'Micro frontend config value',
        },
      ],
    },
  }
/>

Paso de datos de vuelta a la aplicación shell​

Para pasar datos de un microfrontend a la aplicación shell, puede pasar una función de devolución de llamada del shell al microfrontend. Cuando el microfrontend invoca esta devolución de llamada con argumentos, la aplicación shell recibe esos argumentos y puede procesar los datos según sea necesario.

Note: Cuando intente pasar datos, asegúrese de que las devoluciones de llamada personalizadas se pasen como propiedades del componente MicroFrontend y no estén anidadas dentro de la propiedad jutro.

En las siguientes secciones, se muestra cómo pasar datos desde el microfrontend a la aplicación shell mediante la función de devolución de llamada:

Código de la aplicación shell​

export const MyMicroFrontend = () => {
  const handleMicroFrontendData = useCallback((data) => {
    console.log('Received data from micro frontend:', data);
  });

  return (
    <MicroFrontend
      src="myapp@http://localhost:3001"
      jutro={{
        mode: 'shared',
      }}
      // Callback
      exampleCallback={handleMicroFrontendData}
    />
  );
};

Código de microfrontend​

export const ExampleCallbackContext = React.createContext({
  exampleCallback: (data) =>
    console.log('Default callback used in eg. MFE standalone mode', data),
});

export const Jutro = ({ exampleCallback, ...props }) => {
  return (
    <ExampleCallbackContext.Provider value={{ exampleCallback }}>
      <AppRoot {...props} />
    </ExampleCallbackContext.Provider>
  );
};

export const SomeComponentOnSomePage = () => {
  const { exampleCallback } = useContext(ExampleCallbackContext);
  return (
    <Button
      onClick={() => exampleCallback('Data from MFE')}
      label="Trigger example callback"
    />
  );
};

Restricciones de propiedades​

Cuando se utiliza el modo aislado, todas las propiedades pasadas a microfrontends deben ser serializables en JSON. Jutro también admite el paso de devoluciones de llamada, pero los argumentos que se les pasan también deben ser serializables de la misma manera.

Para obtener más información, consulte The structured clone algorithm: supported types (Algoritmo de clonación estructurada: tipos compatibles).

Correcto
<MicroFrontend
  jutro={{ mode: 'isolated' }}
  validProp="Strings are serializable"
  anotherValidProp={['apples', 'oranges', 'berries']}
  finallyAFunctionProp={() => {
    setOpen(false);
  }}
/>
Incorrecto
<MicroFrontend
  jutro={{ mode: 'isolated' }}
  invalidProp={<span>React Element are not serializable</span>}
  anotherInvalidProp={document.getElementById('DOM-nodes-are-not-serializable')}
/>

Microfrontends autenticados​

Los microfrontends aprovechan los tokens de autenticación obtenidos por sus aplicaciones shell, lo que simplifica la experiencia del usuario porque permite un único flujo de inicio de sesión. Esto significa que, en la mayoría de los casos, los microfrontends no necesitan realizar flujos de autenticación, lo que simplifica su uso. Sin embargo, para que este método funcione de manera eficaz, especialmente cuando se trata de Guidewire Hub y API de servidor, se deben tener en cuenta ciertos aspectos.

Cuando se prevé que un microfrontend realice llamadas a las API del servidor, es fundamental que el token que utiliza sea emitido por Guidewire Hub. Estas API solo aceptan tokens de Guidewire Hub, por eso, el uso de un token de otra fuente hará que las llamadas a la API fallen. Además, debido a que las aplicaciones de JDP no validan al emisor de un token, pasar un token que no sea de Guidewire Hub a un microfrontend hará que el microfrontend suponga erróneamente que el usuario está autenticado e intente usar el token, lo que provocará fallas al interactuar con las API de InsuranceSuite.

Cuando la integración de autenticación esté habilitada, el componente AuthProviderStatic se utiliza en el microfrontend para rellenar los tokens desde el shell, sin contener ninguna lógica de autenticación. Cualquier intento de llamar a login() o logout() desde el microfrontend da como resultado un error, ya que estas acciones deben realizarse en el shell.

En las situaciones en las que el microfrontend esté incrustado en un iframe, hay dos opciones:

  1. (Recomendada) integración de la aplicación shell con Guidewire Hub. La aplicación shell obtiene el token de autenticación de Guidewire Hub y lo pasa al microfrontend. En el caso de las aplicaciones shell de Jutro, utilice la biblioteca @jutro/auth para la autenticación. En el caso de aplicaciones de terceros, intégrelas utilizando el SDK de autenticación de Okta.

  2. Integración de microfrontend con Guidewire Hub. Si la aplicación shell obtiene el token del proveedor de identidad externo (IdP), es esencial no pasar ese token directamente al microfrontend. En cambio, el microfrontend debe iniciar su propio proceso de reautenticación utilizando la sesión de IdP externa. Este proceso consiste en detectar la sesión existente a través de cookies con el IdP externo, que Guidewire Hub utiliza luego para emitir un nuevo token. Tenga en cuenta que esta opción tiene ciertas consecuencias de UX para los usuarios, como la aparición de ventanas emergentes. Los usuarios también deben deshabilitar los bloqueadores de ventanas emergentes de su navegador.

En ambos casos, el microfrontend puede utilizar luego este token emitido por Guidewire Hub para llamar correctamente a las API de InsuranceSuite. Si la integración de autenticación está deshabilitada, el shell y el microfrontend utilizan tokens independientes e inician flujos de autenticación separados. El iframe abre una ventana emergente para la autenticación, preserva el estado del shell al realizar el flujo de autenticación en la ventana emergente y la cierra posteriormente.

Note: Si utiliza el cliente de autenticación nativo de Okta y ya existe una sesión de autenticación, el microfrontend utiliza la sesión existente para obtener un token sin abrir una ventana emergente. Sin embargo, esto solo funciona si la aplicación shell y el microfrontend están en el mismo dominio o si se permiten cookies de terceros. Si no se permiten las cookies de terceros, la ventana emergente se abre por un breve momento.

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 este caso, se 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.

Casos de uso​

Globalización​

La integración de la globalización sincroniza la configuración regional y de idioma en la aplicación shell y los microfrontends. Cualquier cambio en estos valores del shell o de los microfrontends afecta inmediatamente a la otra aplicación. La integración también propaga la configuración de localización predeterminada desde el shell hasta los microfrontends. 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;
};

Para desactivar la integración, configure la propiedad integrateG11n en false. En este caso, los microfrontends usan su propia configuración de localización predeterminada y cualquier cambio en locale o language no afecta a otras aplicaciones.

Note: Los ajustes de la configuración regional definidos en configOverrides.localeSettings tienen prioridad sobre los valores de integración. Úselos cuando desee especificar una configuración regional para un microfrontend y asegúrese de que permanezca sin cambios durante el tiempo de ejecución de la aplicación.

configOverrides.localeSettings invalida los valores predeterminados del shell cuando pasan a una aplicación de microfrontend.

El microfrontend utiliza configOverrides.localeSettings incluso si la integración está deshabilitada y solo proporciona valores iniciales. Cuando la integración está habilitada, propaga los cambios de los ajustes de la configuración regional o del idioma a otras aplicaciones.

En el siguiente ejemplo, se muestra cómo configurar la globalización en un microfrontend:

const SampleApp = () => {
  const globalizationSettings = {
    preferredLocale: 'en-EN',
    preferredLanguage: 'en-EN',
    defaultCountryCode: 'US',
    defaultCurrency: 'USD',
    defaultTimezone: 'GMT',
  };

  return <Microfrontend jutro={{ g11n: globalizationSettings }} />;
};

Para habilitar la integración de modal, configure la propiedad integrateModal en true. Esto le permite desencadenar un modal desde el microfrontend para que luego lo muestre la aplicación shell.

Cuando se establece integrateModal en true, los modales desencadenados desde un microfrontend incrustado se muestran en el centro de la ventana del shell y utilizan las funciones showAlert y showConfirm desde el contexto modal del shell.

Cuando integrateModal se establece en false, los modales activados desde un microfrontend incrustado se muestran en el centro del contenedor de microfrontend.

<MicroFrontend
  jutro={{
    ...
    integrateModal: true
    },
  }
/>
...
  const handleShowModal = () => {
    showModal(
      <CustomModalExample />
    );
  };

  const handleShowAlert = () => {
    showAlert({
      title: 'Alert Title',
      message: 'This is an alert message.',
    });
  };

  const handleShowConfirm = () => {
    showConfirm({
      title: 'Confirm Title',
      message: 'Are you sure you want to proceed?',
      onConfirm: () => {
        ...
      },
    });
  };

  return (
    <div>
      <button onClick={handleShowModal}>Show Custom Modal</button>
      <button onClick={handleShowAlert}>Show Alert</button>
      <button onClick={handleShowConfirm}>Show Confirm</button>
    </div>
  );
...
Note: Los modales personalizados, que se muestran al llamar a la función showModal desde el contexto modal, devueltos desde useModal(), no se integran. Esta limitación existe porque no es posible enviar elementos de React personalizados. Por lo tanto, la integración modal se limita a las funciones que usan solo parámetros serializables. En consecuencia, cuando se activa showModal en un microfrontend, se comporta como si integrateModal estuviera configurado en false.

Para obtener más información acerca de los modales personalizados, consulte la documentación sobre el componente modal y la página del componente modal de Storybook .

Traducciones en modales​

Si los modales incluyen traducciones que solo están disponibles en el microfrontend y se establece integrateModal en true, la aplicación shell no podrá acceder a las traducciones cuando se muestre la aplicación. Hay varias soluciones alternativas para este problema:

Traducir del contenido antes de llamar a la función modal​

Puede traducir los mensajes antes de llamar a las funciones modales mediante la función useTranslator() del paquete @jutro/locale:

import { useModal } from '@jutro/components';
import { useTranslator } from '@jutro/locale';
function MyComponent(props) {
    ...
    const { showConfirm } = useModal();
    const translator = useTranslator();

    const handleShowConfirm = async () => {
        const result = await showConfirm({
            title: messages.requiresApprovalHeader,
            message: translator(messages.requiresApproval, { value: translator(value.label) }),
            confirmButtonText: messages.confirm,
            cancelButtonText: messages.cancel,
        });
    };

    return (
        <button onClick={handleShowConfirm}>
            {translator(messages.showConfirmButton)}
        </button>
    );
}
Usar showModal en lugar de showConfirm​

Puede utilizar showModal en lugar de showConfirm. No tiene el mismo problema que showConfirm, sino que showModal se ejecuta dentro del microfrontend y renderiza el modal desde adentro. Para obtener más información, consulte la documentación del componente modal.

Note: Para cualquier componente MicroFrontend que utilice el modo de aislamiento de contexto, el cuadro de diálogo de showModal se limitará al iframe del MFE y dará lugar a una mala experiencia de usuario, además de romper las características de accesibilidad, por eso, no se recomienda.
Establecer integrateModal en false​

Puede establecer integrateModal en false en su lugar y evitar usar la integración modal.

Important: Establecer jutro: { integrateModal: false } para un componente MicroFrontend mediante el modo compartido de contexto funciona visualmente. Sin embargo, rompe las características de accesibilidad y no se recomienda.

Navegación del enrutador anidado​

Cuando se utiliza el componente <MicroFrontend> en modo isolated, el microfrontend y la aplicación shell tienen un contexto de navegación diferente. Esto significa que los objetos de ubicación e historial del navegador no se comparten entre el microfrontend y la aplicación shell.

Los microfrontends detectan automáticamente el nombre base de su enrutador en función de la URL de la aplicación shell en el momento en que se montan. Si desea establecer un nombre base explícito, pase la propiedad jutro.router.basename a su microfrontend.

Por ejemplo, si se pasa el siguiente nombre base, se conserva la ruta /welcome de la aplicación shell como prefijo base en todas las rutas del microfrontend:

<MicroFrontend
  src={getMicroFrontendSrc('claimMicroFrontend')}
  jutro={{
    router: {
    basename: '/welcome'
      },
    },
  }
/>

La integración del enrutador se puede desactivar mediante integrateRouter: false, lo que evita cambios en la barra de ubicación del navegador y actualizaciones en el historial de shell.

Integración de notificaciones del sistema​

Para habilitar la integración de notificaciones del sistema, configure la propiedad integrateToast en true. De esta manera, puede activar un mensaje de notificación del sistema desde el microfrontend para que se muestre en la aplicación shell. Cuando integrateToast se establece en true, los microfrontends y la aplicación shell comparten el mismo proveedor notificaciones del sistema, mientras que establecerlo en false permite que cada microfrontend y aplicación shell tenga su propio proveedor independiente.

<MicroFrontend
  jutro={{
    ...
    integrateToast: true
    },
  }
/>
...
const addToast = () =>
        ToastProvider.toast({ message: 'Application toast', autoClose: false });
    <Button
        size="small"
        onClick={addToast}
        label="Application Toast"
    />

Uso con cargador personalizado y límite de error​

Ejemplos del componente microfrontend que se utiliza con propiedades personalizadas:

const MyLoader = () => (
  <div className={customComponentStyles.customLoaderContainer}>
    <span className={customComponentStyles.customMfeLoader} />
  </div>
);

class MyErrorBoundary extends React.Component<
  { children: React.ReactNode, fallbackComponent?: React.ComponentType },
  { error?: Error }
> {
  constructor(props) {
    super(props);
    this.state = { error: null };
  }

  componentDidCatch(error) {
    this.setState({
      error,
    });
  }

  render() {
    const { fallbackComponent: FallbackComponent } = this.props;

    if (this.state.error) {
      return (
        <span>
          {this.state.error.toString()}
          <FallbackComponent />
        </span>
      );
    }

    return this.props.children;
  }
}

const MyMicroFrontend = () => (
  <MicroFrontend
    src={getMicroFrontendSrc('claimMicroFrontend')}
    loaderComponent={MyLoader}
    errorBoundaryComponent={MyErrorBoundary}
    otherProp={someValue}
  />
);
Warning: Si se usan cargadores personalizados y límites de error propios, se invalida la lógica de configuración base para la renderización y el manejo de errores.

Esto puede ocasionar problemas de tiempo de ejecución.

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

El footer y header de un microfrontend creado con MicroFrontend component in context isolation mode están ocultos de forma predeterminada, aunque subHeader sigue siendo visible en ciertos puntos de interrupción. Para mostrar estos elementos en su microfrontend, debe renderizarlos dentro del microfrontend junto con su contenido utilizando los componentes Grid o Flex. En el siguiente ejemplo, se muestra un método para renderizar el pie de página:

// your-app/src/app/App.tsx

import { Flex } from '@jutro/layout';
import { Footer } from '../components/Footer';

export const AppRoot = props => {
    // existing content here

    return (
        <Flex direction="column">
            <AppFloorPlan floorPlans={floorPlans} />
            <Footer className={undefined} />
        </Flex>
    );
}
Note: El componente pie de página de la plantilla de la aplicación de Jutro no viene con estilo de forma predeterminada, sino que lo hereda a través de la propiedad className pasada internamente desde el componente plano de planta. No hay otra forma de acceder a los estilos del pie de página de los planos de planta, por eso, debe definir el estilo del pie de página usted mismo.

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.

<MicroFrontend
  jutro={{
    mode: 'isolated',
    iframeAttributes: {
      allow: 'geolocation; camera "none"',
      referrerpolicy: 'noreferrer',
      sandbox: 'allow-scripts',
    },
  }}
/>

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>
);