Exposition et intégration avec le microfrontend SDK

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>

N'oubliez pas que 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,
  });
};

Démarrez votre application :

npm i
PORT=3001 npm run start

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

Le microfrontend SDK vous permet d'intégrer votre module micro front-end dans n'importe quelle application Web. L'application shell n'a pas besoin d'être une application Jutro. Il n'est même pas nécessaire qu'il s'agisse d'une application React. La seule condition à laquelle votre application doit répondre est qu'elle doit être exposée en tant que module micro front-end. Les applications iframe respectent les propriétés transmises par leurs applications shell en ce qui concerne le comportement de Jutro.

Vous pouvez ensuite l'intégrer en suivant cet exemple :

<script src="http://your-app.com/sub-path/jutro-micro-frontends.js"></script>
<script>
  const selector = document.getElementById('micro-app-container');
  const renderer = JutroMicroFrontends.createRoot(
    selector,
    'claimMicroFrontend@http://your-app.com'
  );
  renderer.render(appSettings);
  // appSettings: see example below for details
</script>

Note: Pour le script src, https://your-app.com/sub-path correspond à l'URL vers laquelle votre module micro front-end est déployé. Vous devriez pouvoir le voir au niveau de l'URL que vous spécifiez, mais il s'affichera en mode autonome, sans aucune application shell autour.

Note: L’ID d’application (par exemple, claimMicroFrontend dans 'claimMicroFrontend@http://your-app.com') identifie de manière unique votre micro front-end par rapport à l’application shell. Pour en savoir plus sur la définition de l'ID de votre application, consultez la section Définition de l’ID d’application de votre micro front-end.

Vous spécifiez le module micro front-end que vous souhaitez intégrer, comme indiqué à la première ligne de l'exemple. <script /> crée ensuite une propriété d'objet de fenêtre window.JutroMicroFrontends. Actuellement, il s'agit de la seule façon d'utiliser le microfrontend SDK. Le SDK présente également une limitation d'un seul module micro front-end intégré à la fois.

integrateJutro permet d'activer et de désactiver plusieurs intégrations. Cette propriété, comme le reste des options d'intégration, est définie sur false. Pour en savoir plus sur toutes les propriétés disponibles, reportez-vous à la section Référence API micro front-end.

Notez que l'authentification n'est pas gérée automatiquement lors de l'utilisation du microfrontend SDK. Pour en savoir plus, reportez-vous à la section Authentification.

Transmission des propriétés

Pour transmettre des propriétés personnalisées lors de l'utilisation du microfrontend SDK, transmettez-les sous forme de paires clé-valeur à la fonction render().

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

Vos propriétés personnalisées sont transmises au composant <AppRoot> dans votre micro front-end.

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

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

Authentification

Vous pouvez activer l'intégration de l'authentification en définissant la propriété integrateAuth sur true. Par défaut, cette intégration est activée.

Pour que vos applications communiquent des informations d'authentification, vous devez transmettre des jetons d'authentification à l'aide de la propriété auth. Elle accepte les arguments suivants :

accessToken : jutro.auth.accessToken - Chaîne
idToken : auth?.idToken - Chaîne
userInfo : auth.userInfo - OidcUserInfo | null. Lorsque vous activez l'intégration de l'authentification, ce paramètre est requis.

{
  jutro: {
    integrateAuth: true;
    auth: {
      accessToken: 'access-token',
      idToken: 'id-token',
      userInfo: {
          ...
          name: 'name',
          email: 'mymail@mail.com'
          ...
      }
    }
  }
}

L'application shell est responsable de l'actualisation des jetons. Les jetons doivent être actualisés avant d'expirer pour éviter d'interrompre le travail de l'utilisateur. Le client d'authentification Jutro s'en charge automatiquement.

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, il affiche l'avertissement suivant : 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.

Compatibilité des versions

Les applications shell plus anciennes qui utilisent Jutro, mais qui sont antérieures à Jutro 8, où le composant MicroFrontend (MicroApp dans les anciennes versions de Jutro) a été incrémenté pour prendre en charge le mode isolé, peuvent toujours utiliser la bibliothèque d’aide pour importer des applications iframe modernes à partir de n’importe quelle version. Notez que l’intégration des fonctionnalités Jutro et le partage d’état nécessitent davantage de travail.

Cas d'utilisation

Globalisation

La propriété g11n vous permet d'écouter les modifications de globalisation dans l'application iframe et d'y réagir en maintenant votre application shell synchronisée. L'intégration de la globalisation nécessite une implémentation du côté shell. 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;
    onGlobalizationChange(changeObject)
};

Le rappel onGlobalizationChange est exécuté lorsqu'un module micro front-end modifie ses paramètres régionaux ou sa langue. changeObject accepte les valeurs suivantes :

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

L'exemple suivant montre comment configurer les paramètres de globalisation et gérer les modifications des paramètres régionaux et de langue dans un module micro front-end :

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

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

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

configOverrides.localeSettings remplace les valeurs spécifiées dans la propriété g11n. Il n'est pas recommandé de l'utiliser lorsque votre application avec le SDK fournit une intégration personnalisée avec g11n.

Remplacements Jutro

configOverrides de Jutro est toujours pris en charge et peut être transmis normalement :

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

Intégration des fenêtres modales

Les fenêtres modales peuvent également être intégrées pour couvrir l'écran en dehors de la zone iframe. Pour ce faire, transmettez les fonctions modales prises en charge à partir de l'application shell :

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

Le microfrontend SDK n'a pas la capacité d'afficher l'interface utilisateur dans le contexte de l'application shell. Pour afficher une fenêtre modale dans l'application shell, intégrez directement la fenêtre modale au reste de l'application shell. Le microfrontend SDK ne peut pas contrôler les fonctionnalités de l'application shell telles que le style, l'arborescence d'accessibilité ou les modules d'écoute d'événements.

Contrairement au composant MicroFrontend, qui s'intègre de manière transparente aux applications Jutro basées sur React pour gérer les fenêtres modales, l'iframe microfrontend SDK Jutro fonctionne indépendamment de ces intégrations. 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 modales qui utilisent des paramètres sérialisables.

Si les fenêtres modales reposent sur des traductions de chaînes disponibles uniquement dans l'application iframe, la traduction doit être effectuée avant d'appeler les fonctions modales. Le microfrontend SDK n'inclut pas de fonctionnalités de traduction de messages. Lors de la transmission d'un objet de message comme showAlert({ id: "my-message", defaultMessage: "Some text" }), l'application shell reçoit un objet de message non traduit :

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

Pour afficher le texte approprié dans la fenêtre modale, effectuez la traduction du côté shell à l'aide des outils de traduction disponibles ou terminez la traduction dans le module micro front-end avant d'appeler la fenêtre modale.

Généralement, si vous intégrez un iframe dans une page, l'actualisation de la page recharge l'application iframe. Par conséquent, l'application iframe perd son état. Le microfrontend SDK Jutro a résolu ce problème en permettant à l'application shell, et uniquement à celle-ci, d'être la seule source de vérité pour le routage. Cela vous permet de gérer les routes et l'historique tout en préservant l'état de n'importe quel emplacement dans l'application, y compris les emplacements affichés par l'application iframe.

Étant donné que votre application shell peut correspondre à n'importe quel type d'application Web et pas nécessairement à une application Jutro, vous pouvez utiliser la bibliothèque de routage de votre choix. L'application iframe peut alors écouter les modifications de navigation dans l'application shell et mettre à jour son emplacement et son historique grâce à la propriété router.

La propriété router est définie comme suit :

export type RouterIntegrationProps = {
  location?: string;
  onLocationChange?: (
    pathname: string,
    action: 'PUSH' | 'REPLACE' | 'GO'
  state?: unknown,
  ) => void;
  state?: unknown;
};

location : l'emplacement souhaité, par rapport à l'application shell
onLocationChange : rappel facultatif déclenché par le module micro front-end intégré lorsque l'utilisateur navigue ou qu'il est redirigé. Il n'est requis que lorsque l'application shell doit gérer les changements de route. Le rappel onLocationChange reçoit les arguments suivants :
- pathname : le nouvel emplacement où le module micro front-end souhaite se trouver ; il est relatif à l'emplacement où le module micro front-end est intégré dans l'application shell
- action : l'action qui a déclenché la modification de navigation
- state : l'objet d'état associé au nouvel emplacement ; pour en savoir plus, reportez-vous à la documentation MDN sur pushState().
onBlockChange : permet d'utiliser l'API history.block, qui peut empêcher les utilisateurs de quitter la page en cours, par exemple, lorsqu'ils ont des données non sauvegardées. Le rappel onBlockChange est appelé avec isBlocked=true et un rappel d'invite facultatif lorsque le module micro front-end souhaite bloquer la navigation. Il peut être appelé avec isBlocked=false lorsque le blocage est libéré après l'appel de unblock dans le module micro front-end. Cette méthode accepte les arguments suivants :
- isBlocked : booléen
- prompt : invite facultative

L'argument action peut être l'un des suivants :

PUSH : l'utilisateur a accédé à un nouvel emplacement
REPLACE : l'utilisateur a accédé à un nouvel emplacement, en remplaçant l'emplacement actuel dans l'historique
GO : l'utilisateur a navigué en arrière ou en avant, l'emplacement sera une valeur indiquant le nombre d'étapes nécessaires pour revenir en arrière ou avancer. Par exemple, -3 signifie que nous revenons 3 étapes en arrière dans l'historique.

L'argument state n'est utile que lorsque action est PUSH ou REPLACE.

Voici un exemple dans lequel nous créons une application shell qui a une route /claims et nous voulons intégrer l'application micro front-end dans cette route. Dans cet hypothétique module micro front-end, nous disposons des routes suivantes :

/ : la liste de tous les sinistres
/new : le formulaire pour créer un nouveau sinistre
/:claimId/edit : le formulaire pour modifier un sinistre existant

Le rappel onLocationChange peut être utilisé pour mettre à jour l'emplacement et l'historique de l'application shell lorsque le micro front-end le parcourt.

Par exemple, si l'utilisateur accède à /claims/new dans l'application shell, l'application iframe peut mettre à jour son emplacement vers /new et l'envoyer à l'historique du module micro front-end. Le module micro front-end peut ensuite utiliser son historique pour naviguer vers l'avant et vers l'arrière.

L'extrait de code suivant montre comment le module micro front-end peut écouter les modifications de navigation dans l'application shell et mettre à jour son emplacement et son historique en conséquence. Nous utilisons l'API du navigateur sans bibliothèques pour garder l'exemple le plus simple possible, mais vous pouvez utiliser n'importe quelle bibliothèque pour gérer l'historique du module micro front-end.

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

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

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

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

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

Si vous désactivez l'intégration du routeur à l'aide de la propriété integrateRouter: false, la barre d'emplacement du navigateur ne change pas et l'historique du shell n'est pas mis à jour puisqu'il n'écoute pas les mises à jour du module micro front-end.

Création de thèmes

Les thèmes Jutro peuvent être déterminés par l'application shell en transmettant les propriétés themeConfig et l'application shell peut également écouter les modifications des thèmes internes.

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

Toasts

Les toasts peuvent également être intégrés pour être affichés en dehors de la zone iframe. Pour ce faire, transmettez le rappel du déclencheur toast à partir de l'application shell :

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

Dans ce cas, il existe une limite : si ces toasts reposent sur des traductions de chaînes uniquement disponibles dans l'application iframe, la traduction des chaînes doit être effectuée avant d'appeler ToastProvider. La valeur finale doit être transmise au toast, sinon le fournisseur d'application shell n'aura pas les traductions nécessaires.

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

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

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

Globalisation

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

Le rappel onGlobalizationChange est exécuté lorsqu'un module micro front-end modifie ses paramètres régionaux ou sa langue. changeObject accepte les valeurs suivantes :

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

L'exemple suivant montre comment configurer les paramètres de globalisation et gérer les modifications des paramètres régionaux et de langue dans un module micro front-end :

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

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

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

Remplacements Jutro

configOverrides de Jutro est toujours pris en charge et peut être transmis normalement :

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

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.

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

Redimensionnement

Les applications iframe Jutro utilisent la bibliothèque iframe-resizer pour gérer le redimensionnement automatique de l'iframe en fonction du contenu de l'application iframe.

Pour que le redimensionnement automatique fonctionne, l'iframe doit être placé à l'intérieur d'un conteneur avec une dimension relative, telle que pourcentage ou vw. Les applications Jutro sont conçues pour gérer le style mobile, généralement sans largeur minimale. C'est pourquoi l'utilisation d'une largeur relative est généralement la solution.

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

Si le style de la page de l'application shell ne restreint pas le conteneur, vous pouvez éviter de définir la largeur, et le conteneur et son iframe se développeront pour prendre toute la largeur disponible.

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.

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

Routage des plans et micro front-ends

Si vous intégrez un module micro front-end dans un plan dans une application shell Jutro avec l'intégration de routage activée, veillez à ne pas définir exact sur true. 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"
      }
    ]
  }
}

Démontage d'un module micro front-end

Pour démonter un module micro front-end, utilisez la méthode unmount() pour le supprimer du DOM et libérer des ressources. L'exemple suivant montre comment utiliser la méthode unmount() :

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

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

renderer.unmount();

Détails de la propriété jutro.OnError

La propriété onError du SDK du micro front-end est une propriété facultative ajoutée dans Jutro 10.10 pour ajouter un rappel appelé lorsqu’une erreur se produit. Ce rappel doit respecter le type suivant :

({ error: Error, errorInfo?:ErrorInfo }) => void

Note: Cela n’a aucun rapport avec la propriété onError de l’élément HTML <iframe> .

Si un rappel est transmis à la propriété OnError, il sera appelé dans deux cas de figure :

Si le micro front-end ne se charge pas et qu'un délai de plusieurs secondes s'est écoulé. Dans ce cas, l’argument errorInfo sera undefined.

Note: Si aucun rappel n’est transmis à onError, une erreur sera générée à l’intérieur de la fonction setTimeout() à la place. Cela ajoutera un journal à la console DevTools, mais ne pourra pas être intercepté à l’aide d’une instruction try/catch.

Si un rappel est transmis à onError, seul le rappel est appelé ; aucun message de journal supplémentaire ni aucune erreur ne seront générés dans setTimeout().

Si le composant de limite d’erreur de niveau supérieur du micro front-end intercepte une erreur. Dans ce cas, l’argument errorInfo provient de React et il est documenté ici dans la puce info sous componentDidCatch(error, info).

Note: La limite d’erreur de niveau supérieur est le composant transmis en tant que propriété errorBoundary à la fonction start(). Pour en savoir plus, reportez-vous aux documents de configuration globale.

Lorsque la propriété onError est définie, elle est transmise en tant que valeur de la propriété onError à la limite d’erreur de niveau supérieur. Lorsque l'élément onError de la limite d’erreur de niveau supérieur est appelé, l'élément onError du shell est également appelé.

Si la limite d’erreur par défaut est utilisée, le comportement existant tel que la journalisation de l’erreur auprès de la console et l’envoi d’événements d’analyse s’il est configuré à cette fin est également préservé.

Si une limite d’erreur personnalisée est utilisée et qu’elle n’appelle pas onError lorsqu’elle détecte une erreur, l'élément onError du shell ne sera pas appelé non plus. Dans ce cas, l’élément onError du shell ne sera appelé que lorsque le micro front-end expirera.

Exemple complet

Application shell

Dans cet exemple, nous avons une application shell qui active les thèmes, la navigation, le toast et la fenêtre modale :

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

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

Transmission des propriétés​

Authentification​

Exigences​

Compatibilité des versions​

Cas d'utilisation​

Globalisation​

Remplacements Jutro​

Intégration des fenêtres modales​

Navigation​

Création de thèmes​

Toasts​

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

Globalisation​

Remplacements Jutro​

Attributs Iframe​

Redimensionnement​

Rechargement d'un module micro front-end​

Routage des plans et micro front-ends​

Démontage d'un module micro front-end​

Détails de la propriété jutro.OnError​

Exemple complet​

Application shell​

É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

Transmission des propriétés

Authentification

Exigences

Compatibilité des versions

Cas d'utilisation

Globalisation

Remplacements Jutro

Intégration des fenêtres modales

Navigation

Création de thèmes

Toasts

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

Globalisation

Remplacements Jutro

Attributs Iframe

Redimensionnement

Rechargement d'un module micro front-end

Routage des plans et micro front-ends

Démontage d'un module micro front-end

Détails de la propriété jutro.OnError

Exemple complet

Application shell