Exposition et intégration du composant MicroFrontend avec isolement du contexte

Note: L'utilisation du composant MicroFrontend avec isolement du contexte était auparavant connue sous le nom de mode iframe. Il est désormais connu sous le nom de mode isolé. Vous pouvez toujours utiliser iframe 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 iframe au mode isolated afin d'éviter de futurs problèmes.

La première étape de ce processus consiste à créer une nouvelle application Jutro, puis à l'adapter en tant que module micro front-end. Ensuite, vous pouvez utiliser ce nouveau module micro front-end au sein d'une autre application Jutro. Dans notre exemple, nous créons une deuxième application Jutro à l'aide de la CLI Jutro qui utilise ensuite le module micro front-end nouvellement créé.

É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>

Important: 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.

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

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

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',
        }
```
Démarrez votre application :

npm i
PORT=3001 npm run start

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

Chargez votre module micro front-end à l'aide du composant MicroFrontend et définissez la propriété src. La propriété src 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 page Référence API micro front-end.

Note: Pour en savoir plus sur l’ID de l’application du module micro front-end, consultez la section Définition de l’ID d’application de votre micro front-end.

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

Démarrez votre application shell :

npm i
PORT=3000 npm run start

Note: Si votre module micro front-end ne se redimensionne pas correctement dans l'application shell, vous devez ajouter l'importation suivante dans le code de votre application : import iframe-resizer/js/iframeResizer.contentWindow.

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 élément 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"
);

Application Shell transmettant les valeurs de configuration au module 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={{
    mode: 'isolated',
    router: {
      basename: '/welcome'
    },
    },
    configOverrides: {
      someConfig: 'Micro frontend config value',
    },
  }
/>

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

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

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

Restrictions de propriété

Lors de l'utilisation du mode isolé, toutes les propriétés transmises aux modules micro front-end doivent être sérialisables au format JSON. Jutro prend également en charge la transmission de rappels, mais les arguments qui leur sont transmis doivent également être sérialisables de la même manière.

Pour en savoir plus, reportez-vous à Algorithme de clonage structuré : types pris en charge

Correct

<MicroFrontend
  jutro={{ mode: 'isolated' }}
  validProp="Strings are serializable"
  anotherValidProp={['apples', 'oranges', 'berries']}
  finallyAFunctionProp={() => {
    setOpen(false);
  }}
/>

Incorrect

<MicroFrontend
  jutro={{ mode: 'isolated' }}
  invalidProp={<span>React Element are not serializable</span>}
  anotherInvalidProp={document.getElementById('DOM-nodes-are-not-serializable')}
/>

Micro front-ends authentifiés

Les modules micro front-end tirent 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 besoin d’effectuer des flux d’authentification, ce qui simplifie leur utilisation. 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.

Lorsque l'intégration d'authentification est activée, le composant AuthProviderStatic est utilisé dans le module micro front-end pour remplir les jetons à partir du shell, sans contenir de logique d'authentification. Toute tentative d'appeler login() ou logout() à partir du module micro front-end génère une erreur, car ces actions doivent être effectuées dans le shell.

Dans les scénarios où le module micro front-end est intégré à un iframe, deux options sont disponibles :

(Recommandé) Intégration de l'application shell à Guidewire Hub : l'application shell obtient le jeton d'authentification auprès de Guidewire Hub et le transmet au module micro front-end. Pour les applications shell Jutro, utilisez la bibliothèque @jutro/auth pour l'authentification. Pour les applications tierces, intégrez-les à l'aide du SDK d'authentification d'Okta.
Intégration du module micro front-end avec Guidewire Hub : si l'application shell obtient le jeton auprès du fournisseur d'identité externe, il est essentiel d'éviter de transmettre ce jeton directement au module micro front-end. Au lieu de cela, le module micro front-end doit lancer son propre processus de réauthentification à l'aide de la session du fournisseur d'identité externe. Ce processus implique la détection de la session existante par le biais de cookies associés au fournisseur d'identité externe, que Guidewire Hub utilise ensuite pour émettre un nouveau jeton. Notez que cette option comporte certaines implications UX pour les utilisateurs, telles que l'affichage de fenêtres contextuelles. Les utilisateurs doivent également désactiver les bloqueurs de fenêtres contextuelles de leur navigateur.

Dans les deux cas, le module micro front-end peut ensuite utiliser ce jeton émis par Guidewire Hub pour appeler les API InsuranceSuite. Si l'intégration de l'authentification est désactivée, le shell et le module micro front-end utilisent des jetons indépendants et initient des flux d'authentification et d'autorisation séparés. L'iframe ouvre une fenêtre contextuelle pour l'authentification, préserve l'état du shell en effectuant le flux d'authentification dans la fenêtre contextuelle et la ferme ensuite.

Note: Si vous utilisez le client d’authentification Okta natif et qu’une session d’authentification existe déjà, le micro front-end utilise la session existante pour obtenir un jeton sans ouvrir de fenêtre contextuelle. Toutefois, cela ne fonctionne que si l’application shell et le micro front-end se trouvent dans le même domaine ou si les cookies tiers sont autorisés. Si les cookies tiers ne sont pas autorisés, la fenêtre contextuelle s’ouvre brièvement.

Exigences

Pour garantir un fonctionnement correct lors de l'intégration d'un module micro front-end avec l'intégration d'authentification activée, il existe des exigences spécifiques concernant la communication sécurisée et les scripts Service Worker. Un script Service Worker s'exécute en arrière-plan dans le navigateur et gère des tâches telles que la gestion des flux d'authentification.

Pour le développement, vous pouvez utiliser localhost avec HTTP, tandis que pour la production, vous devez utiliser des déploiements avec HTTPS. Ces configurations garantissent que les scripts Service Worker fonctionnent correctement lors de la gestion des flux d'authentification. Si le module micro front-end utilise le script Service Worker, le shell et le module micro front-end doivent être déployés sur le même site.

Les configurations suivantes sont considérées comme sécurisées et permettent au script Service Worker de fonctionner correctement :

http://localhost : localhost sur HTTP est traité comme un élément sécurisé, une exception aux politiques de sécurité typiques.
https://example.com/app : une URL HTTPS entièrement valide.
https://localhost : fonctionne avec un certificat auto-signé de confiance.
https://127.0.0.1 : nécessite également un certificat auto-signé de confiance.

Dans les cas où vous utilisez un shell localhost, assurez-vous que le module micro front-end déployé inclut la directive frame-ancestors appropriée dans son en-tête CSP (Content-Security-Policy) pour permettre l'intégration.

Pour les configurations HTTPS localhost sans certificat valide, les scripts Service Worker ne fonctionnent pas, c'est pourquoi Jutro utilise plutôt le stockage de session pour la gestion de l'authentification. Par défaut, Jutro désactive le script Service Worker et utilise le stockage de session pour localhost avec des applications HTTPS. Dans ce scénario, l’avertissement suivant s’affiche :

Le script Service Worker @jutro/auth ne peut être enregistré que pour des origines sécurisées. Vous exécutez un serveur HTTPS local, le stockage de session est donc utilisé comme solution de secours. Si vous souhaitez tester le script Service Worker dans une configuration HTTPS locale, vous devez l'activer explicitement en ajoutant la variable .env REACT_APP_JUTRO_AUTH_HTTPS_LOCALHOST_SERVICE_WORKER=true ou basculer vers une connexion HTTP simple.

Certaines configurations empêchent l'enregistrement des scripts Service Worker, ce qui peut perturber les flux d'authentification. L'impact dépend de la façon dont le module micro front-end interagit avec l'application shell. Si le module micro front-end obtient ses jetons du shell et que l'authentification est activée dans le shell, par exemple, s'il utilise un script service worker, seul le shell doit répondre aux exigences du script Service Worker. Le module micro front-end n'utilise pas le script Service Worker et n'a pas besoin de répondre à ces exigences. Si le module micro front-end n'obtient pas ses jetons du shell, que l'authentification soit activée ou non, le module micro front-end doit utiliser un script Service Worker. Dans ce cas, le module micro front-end et le shell doivent tous deux répondre aux exigences du script Service Worker pour garantir le bon fonctionnement des flux d'authentification.

Les scripts Service Worker ne peuvent pas être enregistrés si le shell ou le module micro front-end fonctionne dans l'une des conditions suivantes, ce qui perturbera les flux d'authentification :

http://127.0.0.1 : n'est pas considéré comme un contexte sécurisé.
http://example.com/app : connexion HTTP non sécurisée.
https://localhost : sans certificat de confiance.
https://example.com/app : si le certificat n'est pas valide.

Cas d'utilisation

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 :

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

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

Lors de l'utilisation du composant <MicroFrontend> en mode isolated, le module micro front-end et l'application shell ont un contexte de navigation différent. Cela signifie que l'emplacement du navigateur et les objets d'historique ne sont pas partagés entre le module micro front-end et l'application shell.

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

L'intégration du routeur peut être désactivée à l'aide de integrateRouter: false, ce qui empêche les modifications de la barre d'emplacement du navigateur et les mises à jour de l'historique de l'application shell.

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

Attributs Iframe

Il est possible de transmettre des attributs supplémentaires pour les modules micro front-end intégrés à l'aide du mode isolé ou du SDK. Cela permet d'activer diverses fonctionnalités du navigateur. Des entrées de la propriété iframeAttributes sont ajoutées à l'élément HTML iframe. Seules les propriétés allow, referrerpolicy et sandbox sont autorisées. Pour en savoir plus sur ces propriétés, reportez-vous au guide de référence de l'API des modules micro front-end.

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

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

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

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

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

src​

Application Shell transmettant les valeurs de configuration au module micro front-end​

Retransmission des données à l’application shell​

Code de l’application shell​

Code du micro front-end​

Restrictions de propriété​

Micro front-ends authentifiés​

Exigences​

Cas d'utilisation​

Globalisation​

Intégration des fenêtres modales​

Traductions dans les fenêtres modales​

Traduire le contenu avant d’appeler la fonction modale​

Utilisez showModal au lieu de showConfirm​

Définir integrateModal sur false​

Navigation de routeur imbriqué​

Intégration de toasts​

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

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

Attributs Iframe​

Rechargement d'un module micro front-end​

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

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

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

src

Application Shell transmettant les valeurs de configuration au module micro front-end

Retransmission des données à l’application shell

Code de l’application shell

Code du micro front-end

Restrictions de propriété

Micro front-ends authentifiés

Exigences

Cas d'utilisation

Globalisation

Intégration des fenêtres modales

Traductions dans les fenêtres modales

Traduire le contenu avant d’appeler la fonction modale

Utilisez showModal au lieu de showConfirm

Définir integrateModal sur false

Navigation de routeur imbriqué

Intégration de toasts

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

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

Attributs Iframe

Rechargement d'un module micro front-end