Passer au contenu principal

Considérations relatives à l'utilisation du micro front-end

Performances de rendu des micro front-ends​

Les modules micro front-end incluent souvent des flux d'applications complets et sont sensibles au remontage ou au rendu inutile de leurs composants parents. Dans React, lorsqu'un composant parent est remonté, il reconstruit l'arborescence React située en dessous.

Bien que les petits composants puissent traiter rapidement les remontages ou les rendus parents, cela peut ne pas être le cas pour l'ensemble d'une application. Assurez-vous donc que le composant parent dans lequel vous placez votre module micro front-end est stable en termes de performances de rendu. De cette manière, votre module micro front-end ne reproduit pas inutilement l'ensemble de son arborescence.

Pour identifier les problèmes de rendu dans les composants parent du micro front-end, vous pouvez utiliser l'onglet Profiler dans les outils de développement React.

Les applications micro front-end sont résilientes aux rendus dans l'application shell.

Quand utiliser le fichier index.js​

Le fichier index.js n'est utilisé que lorsque l'application est utilisée en mode autonome étant donné qu'aucun élément mfeData n'est transmis. Lorsque le module micro front-end est intégré, l'application shell appelle la fonction startApp pour obtenir l'élément mfeData pertinent et le fichier index.js est ignoré.

Authentification des modules micro front-end​

Lorsque l'intégration de l'authentification est activée, l'application shell gère le cycle de vie du jeton, offrant ainsi une meilleure expérience utilisateur. La désactivation de l'intégration de l'authentification entraîne la création de flux d'authentification distincts pour l'application shell et les modules micro front-end, chacun utilisant des jetons indépendants. Notez que les modules micro front-end avec partage de contexte ne peuvent pas avoir d'authentification indépendante lorsque l'intégration est désactivée.

Le tableau suivant montre la compatibilité pour chaque scénario :

ScénarioComposant micro front-end avec partage de contexte (mode partagé)Composant micro front-end avec isolement du contexte (mode isolé)Microfrontend SDK
Intégration activée, le shell et le MFE disposent tous les deux d’une authentificationOuiOuiOui
Intégration désactivée, le shell et le MFE disposent tous les deux d’une authentificationNonOuiOui
Intégration désactivée, seul le shell dispose d’une authentificationOuiOuiOui
Intégration désactivée, seul le MFE dispose d’une authentificationNonOuiOui

Lorsque l'application shell est une application JDP de confiance qui peut s'intégrer à Guidewire Hub pour obtenir un jeton d'authentification, elle peut transmettre ce jeton de manière transparente au module micro front-end. Cela crée une expérience utilisateur fluide dans laquelle le processus d'authentification est transparent pour l'utilisateur une fois qu'il s'est connecté via l'application shell.

Pour les applications shell autres que Jutro, si l'application shell est une application de confiance, par exemple, une application appartenant à l'organisation et qu'elle peut s'intégrer à Guidewire Hub pour obtenir un jeton d'authentification, par exemple en utilisant OIDC, elle peut également transmettre ce jeton au module micro front-end. Ce scénario se traduit également par une expérience utilisateur fluide similaire à celle des applications Jutro, où le flux d'authentification est invisible pour l'utilisateur après sa connexion.

Si l'application shell n'est pas approuvée, par exemple, s'il s'agit d'un portail tiers que l'organisation ne possède pas, ou si elle ne peut pas s'intégrer à Guidewire Hub pour obtenir un jeton d'authentification, le module micro front-end doit lancer le flux d'authentification indépendamment. Dans ce scénario, le module micro front-end doit obtenir le jeton d'authentification auprès de Guidewire Hub par lui-même, ce qui entraîne généralement une expérience utilisateur peu optimale, car l'utilisateur est invité à se connecter via une fenêtre contextuelle pour obtenir le jeton Web JSON nécessaire.

Note: Il peut exister un scénario dans lequel un module micro front-end comporte un élément auth activé et que le shell possède un élément auth désactivé. Dans ce cas, le module micro front-end ouvre une fenêtre contextuelle lorsque vous essayez de vous connecter.

La fenêtre contextuelle propose deux options :

  • Autorisation accordée. Recharger : ce bouton active les fenêtres contextuelles dans le navigateur et recharge le module micro front-end. Cette option reste en vigueur jusqu'à ce que vous changiez les paramètres de votre navigateur.

  • Ouvrir manuellement : ce bouton vous permet d'ouvrir l'écran de connexion manuellement. Cette option s'affiche chaque fois qu'un module micro front-end nécessite une connexion.

Boutons d'autorisation

Renouvellement passif des jetons des modules micro front-end​

Le renouvellement passif des jetons a été introduit dans la version 10.10. Le renouvellement actif n'est pas obsolète, mais il est recommandé de passer au renouvellement passif. Pour activer cette fonctionnalité, vous devez suivre les étapes suivantes :

  1. Supprimez les variables JUTRO_AUTH_SILENT_REDIRECT_PATH et JUTRO_AUTH_SILENT_LOGIN_PATH le cas échéant. Ces variables sont spécifiques à l'approche active avec connexion silencieuse et ne sont pas nécessaires à l'approche passive.
  2. Ajoutez offline_access à la variable JUTRO_AUTH_SCOPE.
  3. Assurez-vous que la configuration de l'application Guidewire Hub inclut l'octroi REFRESH_TOKEN dans sa série authSettings.grantTypes.
  4. Ajoutez la variable JUTRO_AUTH_USE_PASSIVE_TOKEN_RENEWALS=true.
  5. Remplacez les utilisations suivantes des propriétés à partir du crochet useAuth :
Renouvellement actifRenouvellement passif
isAuthenticated: boolean | nullgetIsAuthenticated: () => Promise<boolean | null>
accessToken: string | nullgetAccessToken: () => Promise<string | null>
idToken: string | nullgetIdToken: () => Promise<string | null>
userInfo: OidcUserInfo | nullgetUserInfo: () => Promise<OidcUserInfo | null>

Le renouvellement passif des jetons peut être activé au niveau de l'application shell ou du module micro front-end. Toutefois, il est important de prendre connaissance des scénarios suivants lorsque l'approche de renouvellement des jetons diffère entre l'application shell et l'un de ses modules micro front-end :

  • L'application shell contrôle le cycle de vie du jeton. Si le renouvellement actif de jeton est activé dans l'application shell, alors tous les modules micro front-end avec le renouvellement passif des jetons activé fonctionneront comme si le renouvellement actif de jeton était activé.
  • Si le renouvellement passif des jetons est activé dans l'application shell, alors le renouvellement passif de jeton doit également être activé pour tous les modules micro front-end. Par conséquent, tous les modules micro front-end doivent être mis à jour pour intégrer le renouvellement passif avant la migration de l'application shell.

Sessions persistantes du module micro front-end avec le SDK Digital​

Lors de l’utilisation d’un module micro front-end avec le SDK Digital, un en-tête d’authentification est généré lorsque le SDK est initialisé. Cela peut entraîner des problèmes dans les environnements groupés si un utilisateur navigue entre le module micro front-end et l’application shell, car les utilisateurs peuvent finir par obtenir des données obsolètes à partir d’un autre nœud.

Il existe un paramètre enableStickySession dans les fonctions d’initialisation du SDK Digital, mais ce paramètre ne fonctionne pas comme prévu dans ce scénario. Pour vous assurer qu’un shell et un module micro front-end utilisent les mêmes en-têtes de session persistants, vous devez créer un crochet React personnalisé qui utilise les intercepteurs Axios pour appliquer un en-tête constant.

L’extrait de code suivant fournit un exemple de solution de crochet React pour ce problème :

import { useEffect } from 'react';
import { isNil } from 'lodash';
import { getSdkConfig } from 'src/generated/PcSdk';
import { getFromSessionStorage, setInSessionStorage } from '../utils';

type AxiosRestService = ReturnType<typeof getSdkConfig>['restService'];

type useStickySessionProps = {
  restService: AxiosRestService;
};

export function useStickySession(props: useStickySessionProps): void {
  useEffect(() => {
    let sessionId = getFromSessionStorage('stickySessionId');

    if (isNil(sessionId)) {
      sessionId = crypto.randomUUID();
      setInSessionStorage('stickySessionId', sessionId);
    }

    props.restService.axiosInterceptors.request.use((config) => {
      const correlationId = crypto.randomUUID();

      return {
        ...config,
        headers: {
          ...config.headers,
          'x-gwre-session': sessionId,
          'x-correlation-id': correlationId,
        },
      };
    });
  }, [props.restService]);
}

Pour utiliser cette solution, ajoutez un appel à useStickySession dans votre fichier App.tsx après avoir exécuté la fonction d’initialisation du SDK Digital avec enableStickySession défini sur false.

App.tsx
export const AppRoot: React.FC = (): JSX.Element => {
    ...

    initPcSdkJutro({
        enableStickySession: false,
    });

    useStickySession({ restService: getPcSdkConfig().restService });

   ...
}

Algorithme de résolution CSS des micro front-ends​

Les applications micro front-end ajoutent une classe de wrapper pour chaque règle CSS au cours du développement. Cela vous permet de modifier facilement les styles du module micro front-end. Les noms des classes de wrapper sont lus à partir de l'élément mfeAppId qui est défini dans la variable JUTRO_APP_ID du fichier .env de l’application ou dans le champ webpack.moduleFederation.name du fichier overrides.config.js de l’application. Cet ID est utilisé comme cssScope. Cette règle ne s'applique pas au thème et le style remplace fileURLToPaths. Si cette configuration n'existe pas, la classe de wrapper n'est pas ajoutée.

Par exemple, si un module CSS était défini comme .appHeader {...}, il serait transformé en .mfeAppId . app_App_appHeader {...} dans le lot de sortie. L'application shell connaît le nom du module micro front-end intégré, elle ajoute donc .mfeAppId au conteneur dans lequel le module micro front-end est affiché.

Remplacement des styles Jutro par défaut​

Depuis Jutro 10.0, tous les composants Jutro des applications micro front-end ont augmenté la spécificité des sélecteurs de style. Par exemple, jut__Button__button est maintenant .mfeAppId .jut__Button__button.

Note: La valeur appName provient de la valeur définie dans webpack.moduleFederation.name, dans le fichier overrides.config.js.

L'élément mfeAppId du micro front-end provient de webpack.moduleFederation.name dans le fichier overrides.config.js sauf si JUTRO_APP_ID a été défini.

Cela se produit pour toutes les applications exposées en tant que modules micro front-end, qu'elles soient utilisées via la fédération de modules, iFrame, le microFrontend SDK Jutro ou qu'elles soient accessibles directement en tant qu'applications autonomes. Cet aspect n'est pas non plus configurable.

Cette exigence s'applique aux clients qui utilisent toujours styleOverrides.css, et est nécessaire pour remplacer les styles par défaut de Jutro. styleOverrides.css est un mécanisme de création de thème plus ancien et son utilisation n'est plus recommandée.

Attribution d’un nom à votre micro front-end​

Lorsque vous créez un micro front-end, vous définissez un élément appName dans la méthode start(). Ce n’est pas quelque chose de spécifique aux micro front-ends. appName est défini dans toutes les applications Jutro et est utilisé pour plusieurs fonctionnalités. Pour en savoir plus sur appName et son utilisation, reportez-vous à la documentation sur la configuration globale.

Définition de l’ID d’application de votre micro front-end​

Lorsque vous créez un micro front-end, vous devez également lui définir un ID d’application unique. Cet ID d’application peut être défini à l’un des deux emplacements suivants :

  • À partir de la variable JUTRO_APP_ID dans votre fichier .env.
  • À partir de webpack.moduleFederation.name dans overrides.config.js.

Cet ID d’application unique est ensuite utilisé à plusieurs fins :

  • Il est utilisé comme préfixe pour toutes les classes CSS et les composants personnalisés dans le micro front-end.
  • Il est utilisé pour identifier le micro front-end lorsqu’il est intégré dans une application shell.
Warning: Il est important de donner à chaque micro front-end un ID unique. Lors de l’intégration de plusieurs micro front-ends dans des applications shell, si deux micro front-ends partagent le même ID, cela entraînera la rupture des applications.

Lorsque vous intégrez un micro front-end, l’ID est défini à l’aide de la variable JUTRO_APP_ID dans votre fichier .env ou de moduleFederation.name dans votre fichier overrides.config.js. Si les deux sont définis, la variable JUTRO_APP_ID a la priorité. L’ID d’application est ensuite utilisé comme préfixe pour toutes les classes CSS et les composants personnalisés dans le micro front-end, ainsi que pour l'identifiant du micro front-end. Toutefois, contrairement à appName, JUTRO_APP_ID n’est fourni nulle part à l’utilisateur final.

Cet ID d’application est également utilisé lorsque vous appelez le micro front-end. Par exemple, si vous intégrez le micro front-end à l’aide du composant MicroFrontend, la déclaration du composant ressemblerait à ceci :

<MicroFrontend src="JUTRO_APP_ID_HERE@https://example.com/mfe" ... />

Chargement de la variable d’environnement d’ordre​

La variable d’environnement JUTRO_NEW_CONFIG_LOADING_ORDER n’affecte pas les micro front-ends si elle est définie dans les fichiers de configuration de l’application shell. Cela n’affecte que l’application dans laquelle elle a été définie. Elle peut toutefois être configurée pour affecter le micro front-end à partir de l’application shell en transmettant la variable d’environnement à l’intérieur de la propriété configOverrides lors de l’appel du micro front-end :

jutro: {
    configOverrides: {
        JUTRO_NEW_CONFIG_LOADING_ORDER: true,
    },
}

Lors de la définition de l’ordre de chargement pour le micro front-end, il peut être défini soit dans le fichier .env, soit dans le fichier config.json. Les configurations de l’application shell ne peuvent pas affecter les paramètres du fichier .env du micro front-end, mais uniquement les paramètres du fichier config.json.

La valeur de l’ordre de chargement est vérifiée à deux endroits :

  • Lorsque les configurations sont chargées pour la première fois, la valeur process.env est d’abord vérifiée. Si JUTRO_NEW_CONFIG_LOADING_ORDER n’est pas défini sur true dans le fichier .env, l’avertissement suivant est consigné :

Vous utilisez l’ordre de chargement de l’ancienne configuration. Les variables définies dans votre fichier .env seront prioritaires sur les variables utilisées dans loadConfiguration(...). Pour activer le nouvel ordre de chargement de la configuration, ajoutez JUTRO_NEW_CONFIG_LOADING_ORDER=true à votre fichier .env.

  • Dans chaque appel getConfigValue, pour déterminer l’ordre. Lors de cette vérification, la valeur config.json est d’abord vérifiée, puis si aucune valeur n’est trouvée, la valeur process.env est vérifiée.

Cela signifie que si l’application shell transmet JUTRO_NEW_CONFIG_LOADING_ORDER: true, le micro front-end doit utiliser le nouvel ordre de configuration, mais l’avertissement apparaît quand même. L’inverse est également vrai : si le nouvel ordre de chargement est activé pour le micro front-end, l’application shell peut forcer sa désactivation. Dans ce cas, il n’y aura aucun avertissement. Pour supprimer cet avertissement, la variable d’ordre de chargement doit être définie sur true dans le fichier .env du micro front-end.

Pour en savoir plus sur JUTRO_NEW_CONFIG_LOADING_ORDER, reportez-vous à la page Configuration globale.