Saltar al contenido principal

Exposición e incrustación del componente MicroFrontend con uso compartido del contexto

Note: El uso del componente MicroFrontend con contexto compartido se conocía anteriormente como modo federación de módulos. Ahora se conoce como modo compartido. Todavía puede usar moduleFederation como un valor para la propiedad mode en su código, pero ha quedado obsoleto. Se recomienda actualizar las referencias del modo moduleFederation a shared para evitar problemas futuros.

En esta página, se explican algunos de los detalles técnicos del uso de microfrontends con la característica de uso compartido de contexto en Jutro. Antes de continuar, es importante tener en cuenta que, aunque la tecnología de federación de módulos se usa para habilitar las funciones de uso compartido de contexto, actualmente no se comparten módulos entre la aplicación shell y el microfrontend.

Esta tecnología requiere que la aplicación shell y el microfrontend incrustado tengan la versión 8.13.x de JDP u otra posterior.

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>
Note: 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. Establezca una variable JUTRO_APP_ID única. Esta variable se utiliza como nombre de ámbito. Puede definirla en el archivo .env:

JUTRO_APP_ID=jutroapp

Cuando configure la variable JUTRO_APP_ID, las clases para los componentes personalizados tienen como prefijo este ID.

Note: La variable JUTRO_APP_ID solo se utiliza cuando se configura un componente MicroFrontend en modo compartido. Si se utiliza cualquier otro método de integración, esta variable se ignora.

  1. 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',
            }

    • shared: Punto de entrada para invalidar/ampliar bibliotecas compartidas. Recibe la configuración predeterminada de la biblioteca y prevé la configuración de la biblioteca compartida. De forma predeterminada, esta opción está deshabilitada, ya que existen algunos problemas conocidos.

      exposes: {
        './startApp': './src/startApp',
      },
      shared: ['date-fns'],

      Consulte los documentos oficiales de federación del módulo de Webpack para obtener más información.

    En el archivo config.overrides.js, también puede establecer el nombre de su microfrontend mediante weback.moduleFederation.name (esto también se conoce a veces como scopeName). Esto ha sido reemplazado por la variable de configuración JUTRO_APP_ID, que establece el scopeName automáticamente.

    El weback.moduleFederation.name se utiliza para las aplicaciones que se han creado anteriormente y ya utilizan la configuración name. La práctica recomendada es usar JUTRO_APP_ID a menos que la aplicación sea una aplicación heredada. No configure weback.moduleFederation.name si está creando una aplicación nueva. Si establece este valor, asegúrese de no utilizar el valor jutroapp predeterminado para el nombre:

module.exports = {
  webpack: {
    moduleFederation: {
      name: 'jutroapp',
      exposes: 'jutro-app',
    },
  },
};
Note: Para obtener más información acerca de cómo configurar el nombre en webpack.moduleFederation y el JUTRO_APP_ID, consulte la página Aspectos que deben tenerse en cuenta sobre el uso de microfrontends.
  1. Inicie su aplicación de microfrontend:
npm i
PORT=3001 npm run start

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

Cree una instancia de otra aplicación de Jutro mediante la CLI. Esta será nuestra aplicación shell.

Ahora, siga los pasos a continuación para consumir el microfrontend creado en el paso 2.

  1. Para cargar su microfrontend, utilice el componente MicroFrontend y configure la propiedad src. Esta propiedad 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 sección de referencia de la API de microfrontend.

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

    export const MyMicroFrontend = () => (
      <MicroFrontend
        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

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

Paso de valores de configuración desde la aplicación shell hasta el 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={{
    router: {
      basename: '/welcome',
    },
    configOverrides: {
      someConfig: 'Micro frontend config value',
    },
  }}
/>

Ejemplo de cuando solo desea invalidar launchProps:

const customProp = useMemo(() => ({ someObject: 'some value' }), []);

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

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"
    />
  );
};
Note: En el caso de los microfrontends que utilizan el modo de uso compartido de contexto, puede pasar cualquier dato en cualquier forma, excepto componentes o elementos de React.

Microfrontends autenticados​

Los microfrontends están diseñados para aprovechar 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 tienen que realizar flujos de autenticación por sí mismos y, por eso, son más simples. 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.

Dado que los tokens de aplicación shell se comparten con microfrontends, se recomienda que los microfrontends favorezcan la autorización basada en grupos sobre la autorización basada en ID. Los ID definidos en un archivo .env de microfrontend no aparecerán en el token compartido del shell, porque estos ámbitos están alineados con las configuraciones de la aplicación shell. Para garantizar una experiencia fluida, lo ideal es que las aplicaciones shell administren el flujo de autenticación antes de que se renderice el microfrontend, de modo que el microfrontend no necesite controlar la autenticación más allá de reconocer que es necesaria.

Note: El modo compartido no admite la autenticación independiente. Esto significa que no se admite cuando la integración está deshabilitada: o bien el shell además del microfrontend tienen configurada la autenticación, o bien solo el microfrontend tiene configurada la autenticación.

Casos de uso​

Contexto​

Existe un contexto adicional en el árbol de React de microfrontend llamado AppContext. Puede utilizarlo en su microfrontend para implementar un comportamiento basado en el contexto en el que se renderiza el microfrontend.

AppContext ofrece los siguientes atributos:

  • appMode con respecto al modo de incrustación, shared, isolated o undefined que representan el modo independiente predeterminado.
  • appName para el nombre del microfrontend desde el punto de vista de la aplicación shell o undefined que representa el modo independiente predeterminado.

Para habilitar o deshabilitar características manualmente según el modo de la aplicación, acceda al modo usando AppContext en el microfrontend:

App.js
import { AppContext } from '@jutro/micro-frontends';
import React, { useContext } from 'react';

export const MicroFrontendComponent = () => {
  const { appMode } = useContext(AppContext);

  // [...] existing code

  return <>{appMode === 'isolated' && <div>Something special</div>}</>;
};

Plano de planta de enrutamiento y microfrontends​

Si incrusta un microfrontend dentro de un plano de planta, no establezca exact en true para la configuración de ruta del microfrontend. 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"
      }
    ]
  }
}

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 shared, el microfrontend comparte el mismo contexto de navegación que la aplicación shell. Esto significa que los objetos de ubicación e historial del navegador se comparten entre el microfrontend y la aplicación shell. No se recomienda deshabilitar la integración del router porque puede tener un comportamiento inesperado, ya que ambas aplicaciones comparten el contexto de navegación, y la ubicación y el historial del navegador aún pueden actualizarse.

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'
      },
    },
  }
/>

Si establece el nombre base en /, el microfrontend comparte la misma ruta raíz que la aplicación shell. Todos los enlaces internos dentro del microfrontend deben incluir la ruta al microfrontend, según se define en las rutas del shell, como prefijo. De lo contrario, llevan a las rutas del shell.

Note: También es conveniente cambiar la configuración del enrutador de la aplicación shell para permitir coincidencias inexactas para la página donde se adjunta el microfrontend, a fin de que este se pueda enlazar profundamente de manera directa al actualizar la página.

Enlaces profundos a páginas de microfrontend​

Si su aplicación shell define la ruta /fnol-mfe que representa el componente MicroFrontend y ese microfrontend define una ruta anidada /settlement/:claimIdNumber, puede crear un vínculo profundo directamente a esa página navegando desde el shell hasta /fnol-mfe/settlement/123 (donde 123 es el número real de ID del siniestro). Por ejemplo:

// In the shell app
<button onClick={() => history.push('/fnol-mfe/settlement/123')}>
  Go to settlement
</button>
// or
<Link to="/fnol-mfe/settlement/123">Go to settlement</Link>;

En este caso, la ruta /fnol-mfe de la aplicación shell sigue coincidiendo porque exact: false está establecido para la ruta del microfrontend en el archivo App.config.tsx.

Puede configurar router: { basename: '/fnol-mfe' } en la llamada de microfrontend para indicar al enrutador de microfrontend que elimine /fnol-mfe de la URL antes de hacer coincidir las rutas internas. Para /fnol-mfe/settlement/123, el microfrontend luego coincide con /settlement/:claimIdNumber. Sin este basename, el microfrontend ve la ruta /fnol-mfe/settlement/123 completa y no coincide con /settlement/:claimIdNumber.

<MicroFrontend
  src={getMicroFrontendSrc('fnolMicroFrontend')}
  jutro={{
    router: {
      basename: '/fnol-mfe',
    },
  }}
/>

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

Alojar un microfrontend en el servidor web​

Warning: Dado que la importación de un microfrontend en la aplicación shell depende, en gran medida, de los datos definidos en el archivo asset-manifest.json expuesto por el microfrontend, es fundamental asegurarse de que el servidor web que lo aloja no permita el almacenamiento en caché de este archivo en el lado del cliente. Para ello, adjunte encabezados de respuesta HTTP apropiados a este archivo. Por ejemplo:
Cache-Control: no-cache, no-store, must-revalidate
Expires: 0

Si no se deshabilita el almacenamiento en caché de este archivo, es posible que se presente contenido obsoleto para el microfrontend de forma inesperada, incluso después de haber publicado varias actualizaciones para algunos recursos.

Jutro utilizará los encabezados de solicitud Cache-Control cuando importe un microfrontend. Estos encabezados se deben incluir en la lista Access-Control-Allow-Headers para el recurso de microfrontend en el servidor.

Carga de recursos de imagen​

Dado que el código del microfrontend se renderizará en el dominio y la página de la aplicación shell, las URL de los recursos remotos, como las imágenes, deben tener una ruta de acceso absoluta al recurso, ya que las rutas relativas se resolverían en la implementación de la aplicación shell donde no se encontrará el recurso.

Jutro garantiza automáticamente que se haga referencia a las URL de los recursos incluidos en la lista del asset-manifest.json del microfrontend por su dirección absoluta, apuntando a la implementación del microfrontend. Para que su recurso de imagen aparezca en el asset-manifest.json y aprovechar este manejo automático, impórtelo utilizando un cargador de Webpack como este:

import myImage from './images/my-image.png';

<img
  src={myImage}
  // [...] other image attributes
/>;

De lo contrario, si no conoce la ruta de la imagen en tiempo de compilación, debe asegurarse de que la ruta del tiempo de ejecución sea una dirección absoluta que apunte a la URL donde esté alojada la imagen.

Integración de características de Jutro​

En Jutro se reserva un conjunto de propiedades que se puede pasar a las aplicaciones para ajustar e integrar el comportamiento de Jutro con aplicaciones externas.

Todas estas propiedades son opcionales y todas se pueden pasar con el espacio de nombres de propiedad jutro. Encontrará más información acerca de estas propiedades en la guía de referencia de la API de microfrontend. Puede utilizar integrateJutro para integrar automáticamente todas las características o para desactivar algunas de forma selectiva. Por ejemplo, el siguiente código activa todas las integraciones excepto la integración de temas:

{
  integrateJutro: true,
  integrateTheme: false,
}

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