Passer au contenu principal

Exposition et intégration du composant micro front-end avec partage du contexte

Note: L'utilisation du composant MicroFrontend avec partage du contexte était auparavant connue sous le nom de mode fédération de modules. Il est désormais connu sous le nom de mode partagé. Vous pouvez toujours utiliser moduleFederation comme valeur pour la propriété mode dans votre code, mais cet élément est obsolète. Il est recommandé de mettre à jour toutes les références du mode moduleFederation au mode shared afin d'éviter de futurs problèmes.

Cette page explique certains détails techniques de l'utilisation des modules micro front-end avec la fonctionnalité de partage de contexte dans Jutro. Avant de continuer, il est important de noter que bien que la technologie de fédération de modules soit utilisée pour activer les fonctionnalités de partage de contexte, aucun module n'est actuellement partagé entre l'application shell et le module micro front-end.

Cette technologie nécessite que l'application shell et le micro front-end intégré soient dans une version JDP 8.13.x ou ultérieure.

Étape 1 : Installer le package de micro front-ends​

Procédez à l'instanciation d'une nouvelle application Jutro ou modifiez une application existante basée sur Jutro de façon à ce qu'elle corresponde au micro front-end que vous intégrez.

Dans votre application basée sur Jutro, installez le package @jutro/micro-frontends afin d'avoir accès aux fonctionnalités du micro front-end :

npm i --save @jutro/micro-frontends@<your-jutro-version>
Note: La version du package doit correspondre à vos autres packages Jutro Design System, tels que @jutro/components.
Note:

La dépendance @jutro/auth est désormais facultative pour les packages @jutro/router et @jutro/components . Cependant, @jutro/micro-frontends package nécessite que @jutro/auth soit ajouté aux dépendances de votre application pour être utilisé.

Étape 2 : Exposer une application Jutro en tant que micro front-end​

Après avoir installé le package micro-frontend, suivez ces étapes pour convertir l'application autonome en un module micro front-end que vous pouvez intégrer dans une application shell. Bien qu'elle ait été convertie en module micro front-end, l'application continue de fonctionner en mode autonome.

  1. Dans le référentiel du module micro front-end, assurez-vous que les fichiers src/indexAsync.js et src/startApp.js sont présents et qu'ils ne contiennent pas de conflits git. Si les fichiers ne sont pas présents, créez-les manuellement. Ajoutez ce qui suit à src/indexAsync.js :

    src/indexAsync.js
    import('./startApp').then(({ startApp }) => startApp());

  2. Dans src/startApp.js, remplacez l'élément import de la fonction start par @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';
    /* ... */

    Vous devez appeler la fonction start du micro front-end dans la fonction startApp :

    export const startApp = (mfeData) => {
      start(Jutro, {
        appName: messages.appName,
        appDescription: messages.appDescription,
        mfeData,
      });
    };

  3. Définissez une variable JUTRO_APP_ID unique. Cette variable est utilisée comme nom de champ d'application. Vous pouvez la définir dans le fichier .env :

JUTRO_APP_ID=jutroapp

Lorsque vous définissez la variable JUTRO_APP_ID, les classes des composants personnalisés sont précédées de cet ID.

Note: La variable JUTRO_APP_ID est utilisée uniquement lors de la définition d'un composant MicroFrontend en mode partagé. Si vous utilisez d'autres méthodes d'intégration, cette variable est ignorée.

  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 : point d'entrée pour remplacer/étendre les bibliothèques partagées. Reçoit la configuration de bibliothèque par défaut et attend une configuration de bibliothèque partagée. Par défaut, cette option est désactivée en raison de problèmes connus.

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

      Reportez-vous à la documentation officielle sur la fédération de modules Webpack pour en savoir plus.

    Dans le fichier config.overrides.js, vous pouvez également définir le nom de votre micro front-end en utilisant weback.moduleFederation.name (parfois appelé scopeName). Cet élément a été remplacé par la variable de configuration JUTRO_APP_ID qui définit automatiquement scopeName.

    weback.moduleFederation.name est utilisé pour les applications qui ont été créées précédemment et qui utilisent déjà la configuration name. Il est recommandé d’utiliser JUTRO_APP_ID sauf s’il s’agit d’une application héritée. Ne définissez pas weback.moduleFederation.name si vous créez une nouvelle application. Si vous définissez cette valeur, assurez-vous de ne pas utiliser la valeur par défaut jutroapp pour le nom :

module.exports = {
  webpack: {
    moduleFederation: {
      name: 'jutroapp',
      exposes: 'jutro-app',
    },
  },
};
Note: Pour en savoir plus sur la définition du nom dans webpack.moduleFederation et JUTRO_APP_ID, reportez-vous à la page Considérations relatives à l'utilisation du micro front-end.
  1. Démarrez votre application micro front-end :
npm i
PORT=3001 npm run start

Étape 3 : Intégrer un micro front-end dans une application shell​

Instanciez une autre application Jutro au moyen de la CLI. Il s'agira de notre application shell.

Suivez à présent les étapes ci-dessous pour utiliser le micro front-end que vous avez créé à l'étape 2.

  1. Chargez votre module micro front-end à l'aide du composant MicroFrontend et en définissant la propriété src. Cette propriété accepte l'ID d'application du module micro front-end avec l'URL de l'application. Pour en savoir plus sur cette propriété, consultez la section Référence de l'API du module micro front-end.

    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: Les modules micro front-ends sont automatiquement englobés par les limites d'erreur Jutro ; consultez la page Limite d'erreur pour en savoir plus. Ils utilisent également le composant Chargeur par défaut.

  1. Démarrez votre application shell :

    npm i
    PORT=3000 npm run start

src​

Vous pouvez utiliser la fonction getMicroFrontendSrc avec votre propriété src pour extraire la source de la configuration. Cette fonction récupère l'ID d'application et l'URL de votre module micro front-end.

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

Dans ce cas, vous devez définir microFrontendsConfig dans votre src/config/config.json.

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

Par ailleurs, vous pouvez utiliser la propriété src sans définir l'ID d'application dans la configuration. Il vous suffit de transmettre un mfeAppId@uri. Notez que mfeAppId doit être unique. Il est déterminé dans la configuration de votre module micro front-end.

Par exemple :

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

Transmission des valeurs de configuration de l’application shell au micro front-end​

Les micro front-ends n'accèdent pas aux configurations de l'application shell ou ne les définissent pas, car le stockage des configurations Jutro et les API du package @jutro/config dans l'application shell et les micro front-ends sont isolés les uns des autres.

Toutefois, l'application shell peut toujours fournir les valeurs initiales des configurations du module micro front-end. L'application shell peut également remplacer les propriétés de lancement Jutro transmises à la fonction Jutro start. Pour cela, vous pouvez utiliser l'une ou l'autre de ces propriétés, ou les deux, en fonction de vos besoins :

  • configOverrides : un raccourci, au cas où vous auriez besoin que les configurations Jutro ne soient disponibles que dans l'API getConfigValue.
Note: Ces propriétés sont imbriquées à l'intérieur de la propriété jutro de façon à les séparer des propriétés devant être transmises au micro front-end.

Exemple d'utilisation des deux propriétés de remplacement d'application shell :

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

Exemple lorsque vous souhaitez uniquement remplacer les propriétés de remplacement :

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

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

Retransmission des données à l’application shell​

Pour transmettre des données d’un micro front-end à l’application shell, vous pouvez transmettre une fonction de rappel du shell au micro front-end. Lorsque le micro front-end invoque ce rappel avec des arguments, l’application shell reçoit ces arguments et peut traiter les données selon les besoins.

Note: Lorsque vous essayez de transmettre des données, assurez-vous que vos rappels personnalisés sont transmis en tant que propriétés du composant MicroFrontend et qu’ils ne sont pas imbriqués à l’intérieur de la propriété jutro.

Les sections suivantes montrent comment transmettre des données du micro front-end à l’application shell à l’aide de la fonction de rappel :

Code de l’application 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}
    />
  );
};

Code du micro front-end​

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: Pour les micro front-ends utilisant le mode de partage de contexte, vous pouvez transmettre n’importe quelle donnée sous n’importe quel format, à l’exception des composants React ou des éléments React.

Micro front-ends authentifiés​

Les modules micro front-end sont conçus pour tirer parti des jetons d'authentification obtenus par leurs applications shell, simplifiant ainsi l'expérience utilisateur en permettant un flux de connexion unique. Cela signifie que dans la plupart des cas, les modules micro front-end n'ont pas à se soucier d'effectuer eux-mêmes des flux d'authentification, ce qui les simplifie. Toutefois, pour que cette approche fonctionne efficacement, en particulier lorsqu'il s'agit de Guidewire Hub et d'API de serveur, certaines considérations doivent être prises en compte.

Lorsqu'un module micro front-end doit effectuer des appels vers des API de serveur, il est essentiel que le jeton qu'il utilise soit émis par Guidewire Hub. Ces API acceptent uniquement les jetons de Guidewire Hub, de sorte que l'utilisation d'un jeton provenant d'une autre source entraînera l'échec des appels d'API. En outre, étant donné que les applications JDP ne valident pas l'émetteur d'un jeton, le transfert d'un jeton autre que Guidewire Hub à un module micro front-end amènera le module micro front-end à supposer à tort que l'utilisateur est authentifié et à tenter d'utiliser le jeton, ce qui entraînera des échecs lors de l'interaction avec les API InsuranceSuite.

Étant donné que les jetons d'application shell sont partagés avec les micro front-ends, il est recommandé que les micro front-ends privilégient les autorisations basées sur le groupe par rapport aux autorisations basées sur les ID. Les ID définis dans le fichier .env d'un module micro front-end n'apparaîtront pas dans le jeton partagé du shell, car ces champs d'application sont alignés sur les configurations de l'application shell. Pour garantir une expérience transparente, le flux d'authentification doit idéalement être géré par les applications shell avant que le module micro front-end ne soit affiché, de sorte que le module micro front-end n'ait pas besoin de gérer l'authentification au-delà de reconnaître le fait qu'il soit requis.

Note: Le mode partagé ne prend pas en charge l’authentification indépendante. Cela signifie qu'elle n'est pas prise en charge lorsque l'intégration est désactivée et que l'authentification est configurée à la fois pour l'application shell et le module micro front-end ou que l'authentification est configurée uniquement pour le module micro front-end.

Cas d'utilisation​

Contexte​

L'arborescence React du module micro front-end contient un contexte supplémentaire, appelé AppContext. Vous pouvez l'utiliser dans votre module micro front-end pour implémenter un comportement basé sur le contexte dans lequel le module micro front-end est affiché.

AppContext propose les attributs suivants :

  • appMode concernant le mode d'intégration, shared, isolated ou undefined représentant le mode autonome par défaut.
  • appName pour le nom du module micro front-end du point de vue de l'application shell ou undefined représentant le mode autonome par défaut.

Pour activer ou désactiver manuellement des fonctionnalités en fonction du mode de l'application, accédez au mode au moyen de AppContext dans le module micro front-end :

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>}</>;
};

Routage des plans et micro front-ends​

Si vous imbriquez un micro front-end dans un plan, ne définissez pas exact sur true pour la configuration de route du micro front-end. Sinon, lorsque le module micro front-end accédera à /my-mfe/some-microfront-subpage, il ne correspondra plus exactement à /my-mfe et votre module micro front-end sera désactivé.

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

Globalisation​

L'intégration de la globalisation synchronise les paramètres régionaux et de langue dans l'application shell et les modules micro front-end. Toute modification de ces valeurs dans le shell ou les modules micro front-end affecte immédiatement l'autre application. L'intégration propage également la configuration de localisation par défaut du shell vers les modules micro front-end. L'exemple suivant illustre la structure de la configuration de localisation :

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

Vous pouvez désactiver l'intégration en définissant la propriété integrateG11n sur false. Dans ce cas, les modules micro front-end utilisent leur propre configuration de localisation par défaut et toute modification apportée à locale ou language n'affecte pas les autres applications.

Note: La configuration des paramètres régionaux définie dans configOverrides.localeSettings est prioritaire sur les valeurs d'intégration. Utilisez cette option lorsque vous souhaitez spécifier un paramètre régional pour un module micro front-end et vous assurer qu'il reste inchangé pendant l'exécution de l'application.

Les valeurs par défaut du shell sont remplacées par configOverrides.localeSettings lorsqu'elles sont transmises à une application micro front-end.

Le module micro front-end utilise configOverrides.localeSettings même si l'intégration est désactivée et ne fournit que des valeurs initiales. Lorsque l'intégration est activée, elle propage les modifications apportées aux paramètres régionaux ou de langue à d'autres applications.

L'exemple suivant montre comment configurer les paramètres de globalisation dans un module micro front-end :

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

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

Vous pouvez activer l'intégration des fenêtres modales en définissant la propriété integrateModal sur true. Cela vous permet de déclencher une fenêtre modale à partir du micro front-end pour qu’elle soit ensuite affichée par l’application shell.

Lorsque integrateModal est défini sur true, les fenêtres modales déclenchées par un micro front-end intégré s’affichent au centre de la fenêtre shell et utilisent les fonctions showAlert et showConfirm du contexte modal du shell.

Lorsque integrateModal est défini sur false, les fenêtres modales déclenchées à partir d'un module micro front-end intégré s'affichent au centre du conteneur du module micro front-end.

<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: Les fenêtres modales personnalisées, affichées lors de l'appel de la fonction showModal dans le contexte modal et retournée par useModal(), ne sont pas intégrées. Cette limitation s'explique par le fait que l'envoi d'éléments React personnalisés n'est pas possible. Par conséquent, l'intégration de fenêtres modales est limitée aux fonctions qui utilisent uniquement des paramètres sérialisables. Ainsi, lorsque showModal est déclenché dans un module micro front-end, il se comporte comme si integrateModal était défini sur false.

Pour en savoir plus sur les fenêtres modales personnalisées, reportez-vous à la documentation du composant modal et à la page Storybook du composant modal.

Traductions dans les fenêtres modales​

Si les fenêtres modales comportent des traductions disponibles uniquement dans le micro front-end et que integrateModal est défini sur true, votre application shell ne pourra pas accéder aux traductions lors de l’affichage de l’application. Il existe un certain nombre de solutions à ce problème :

Traduire le contenu avant d’appeler la fonction modale​

Vous pouvez traduire les messages avant d’appeler les fonctions modales à l’aide de la fonction useTranslator() du package @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>
    );
}
Utilisez showModal au lieu de showConfirm​

Vous pouvez utiliser showModal à la place de showConfirm. Elle ne présente pas le même problème que showConfirm, mais showModal s’exécute à l’intérieur du micro front-end et affiche la fenêtre modale de l’intérieur. Pour en savoir plus, reportez-vous à la documentation du composant modal.

Note: Pour tout composant MicroFrontend utilisant le mode d’isolation du contexte, la boîte de dialogue showModal sera limitée à l’iframe du MFE et entraînera une mauvaise expérience utilisateur tout en rompant les fonctionnalités d’accessibilité, ce qui n’est pas recommandé.
Définir integrateModal sur false​

Vous pouvez définir integrateModal sur false à la place et éviter d’utiliser l’intégration modale.

Important: La définition de jutro: { integrateModal: false } pour un composant MicroFrontend à l’aide du mode de partage de contexte fonctionne visuellement. Toutefois, cela casse les fonctionnalités d’accessibilité et n’est pas recommandé.

Navigation de routeur imbriqué​

Lors de l'utilisation du composant MicroFrontend en mode shared, le module micro front-end partage le même contexte de navigation que l'application shell. Cela signifie que l'emplacement du navigateur et les objets d'historique sont partagés entre le module micro front-end et l'application shell. Il n'est pas recommandé de désactiver l'intégration du routeur, car cela peut entraîner un comportement inattendu étant donné que les deux applications partagent le même contexte de navigation, et qu'il serait encore possible de mettre à jour l'emplacement et l'historique du navigateur.

Les modules micro front-end détectent automatiquement le nom de base de leur routeur en fonction de l'URL de l'application shell au moment de leur installation. Si vous souhaitez définir un nom de base explicite, vous pouvez le faire en transmettant la propriété jutro.router.basename à votre module micro front-end.

Par exemple, la transmission du nom de base suivant préserve le chemin d'accès de l'application shell /welcome comme préfixe de base de toutes les routes du module micro front-end :

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

Si vous définissez le nom de base sur /, le module micro front-end partage le même chemin racine que l'application shell. Tous les liens internes au sein du module micro front-end doivent inclure son chemin d'accès, tel que défini dans les routes du shell, sous la forme d'un préfixe. Sinon, ils pointent vers les routes de l'application shell.

Note: Vous pouvez également modifier la configuration du routeur de votre application shell pour autoriser les correspondances inexactes pour la page à laquelle le micro front-end est associé, de façon à ce qu'il puisse être directement ciblé lors d'une actualisation de la page.

Liens profonds vers des pages micro front-end​

Si votre application shell définit la route /fnol-mfe qui affiche le composant micro front-end et que ce micro front-end définit une route /settlement/:claimIdNumber imbriquée, vous pouvez créer un lien profond directement vers cette page en naviguant du shell vers /fnol-mfe/settlement/123 (où 123 est le numéro d’ID de sinistre réel). Par exemple :

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

Dans ce cas, la route /fnol-mfe de l’application shell correspond toujours car exact: false est défini pour la route du micro front-end dans le fichier App.config.tsx.

Vous pouvez définir router: { basename: '/fnol-mfe' } dans l’appel du micro front-end pour indiquer au routeur du micro front-end de supprimer /fnol-mfe de l’URL avant de faire correspondre les routes internes. Pour /fnol-mfe/settlement/123, le micro front-end correspond alors à /settlement/:claimIdNumber. Sans ce basename, le micro front-end voit le chemin complet /fnol-mfe/settlement/123 et ne correspond pas à /settlement/:claimIdNumber.

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

Intégration de toasts​

Vous pouvez activer l'intégration des toasts en définissant la propriété integrateToast sur true. De cette façon, vous pouvez déclencher un message toast à partir du module micro front-end qui sera affiché par l'application shell. Lorsque integrateToast est défini sur true, les modules micro front-ends et l'application shell partagent le même fournisseur toast ; le fait de le définir sur false permet à chaque module micro front-end et application shell d'avoir son propre fournisseur indépendant.

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

Utilisation avec des chargeurs personnalisés et des limites d'erreur​

Exemples du composant micro front-end utilisé avec des propriétés personnalisées :

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 vous utilisez des chargeurs personnalisés et vos propres limites d'erreur, vous remplacez la logique de configuration de base pour le rendu et la gestion des erreurs.

Cela peut entraîner des problèmes au moment de l'exécution.

Affichage d'un en-tête ou d'un pied de page à l'intérieur du module micro front-end​

Les éléments footer et header d'un module micro front-end créé à l'aide de MicroFrontend component in context sharing mode sont masqués par défaut, bien que subHeader soit toujours visible à certains points d'arrêt. Pour afficher ces éléments dans votre module micro front-end, vous devez les afficher à l'intérieur du module micro front-end avec son contenu à l'aide des composants Grid ou Flex. L'exemple suivant présente une méthode d'affichage du pied de page :

// 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: Le composant Pied de page du modèle d'application Jutro n'est pas fourni avec le style par défaut, mais il hérite du style via la propriété className transmise en interne à partir du composant Plan. Il n'existe aucun autre moyen d'accéder aux styles de pied de page du plan. Vous devez donc styliser le pied de page vous-même.

Hébergement d'un micro front-end sur le serveur Web​

Warning: Étant donné que l'importation d'un module micro front-end dans l'application shell repose largement sur les données définies dans le fichier asset-manifest.json exposé par le module micro front-end, il est essentiel de s'assurer que le serveur Web qui l'héberge ne permet pas de mettre ce fichier en cache côté client. Vous pouvez y parvenir en joignant les en-têtes de réponse HTTP appropriés à ce fichier. Par exemple :
Cache-Control: no-cache, no-store, must-revalidate
Expires: 0

Si vous ne désactivez pas la mise en cache de ce fichier, du contenu obsolète peut être servi de manière inattendue pour le micro front-end dans certains cas, même après que plusieurs mises à jour de certaines ressources ont déjà été publiées.

Jutro utilisera les en-têtes de requête Cache-Control lors de l'importation d'un module micro front-end. Ces en-têtes doivent être inclus dans la liste Access-Control-Allow-Headers de la ressource du module micro front-end sur le serveur.

Chargement des ressources d'image​

Étant donné que le code du micro front-end sera affiché dans le domaine et la page de l'application shell, les URL des ressources distantes telles que les images doivent avoir un chemin d'accès absolu vers la ressource, car les chemins relatifs entraînent le déploiement de l'application shell où la ressource n'est pas disponible.

Jutro s'assure automatiquement que les URL des ressources répertoriées dans l'élément asset-manifest.json du module micro front-end sont référencées par leur adresse absolue, pointant vers le déploiement du module micro front-end. Afin que votre ressource d’image soit répertoriée dans asset-manifest.json et puisse tirer parti de ce traitement automatique, importez-la à l’aide d’un chargeur webpack tel que :

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

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

Sinon, si vous ne connaissez pas le chemin d'accès de l'image au moment de la compilation, vous devez vous assurer que le chemin d'exécution est une adresse absolue pointant vers l'URL où l'image est hébergée.

Intégration des fonctionnalités Jutro​

Jutro réserve un ensemble de propriétés qui peuvent être transmises aux applications pour ajuster et intégrer le comportement de Jutro aux applications externes.

Ces propriétés sont toutes facultatives et peuvent toutes être transmises sous l'espace de noms de la propriété sous la forme jutro. Pour en savoir plus sur toutes les propriétés, reportez-vous au guide de référence de l'API des modules micro front-end. Vous pouvez utiliser integrateJutro pour intégrer automatiquement toutes les fonctionnalités ou désactiver de manière sélective des fonctionnalités. Par exemple, le code ci-dessous active toutes les intégrations, à l'exception de l'intégration du thème :

{
  integrateJutro: true,
  integrateTheme: false,
}

Rechargement d'un module micro front-end​

Vous pouvez recharger un micro front-end en transmettant le rappel () => window.location.reload() personnalisé à partir de l'application shell. L'exemple suivant montre comment l'implémenter à l'intérieur d'un bouton :

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

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