Zum Hauptinhalt springen

Verfügbarmachen und Einbetten der MicroFrontend-Komponente mit Kontextisolierung

Note: Die Verwendung der MicroFrontend-Komponente mit Kontextisolierung wurde früher als iframe-Modus bezeichnet. Dies wird jetzt als isolierter Modus bezeichnet. Sie können iframe weiterhin als Wert für die Eigenschaft mode verwenden, dies ist jedoch veraltet. Es wird empfohlen, alle Verweise von Modus iframezu Modus isolated zu aktualisieren, um zukünftige Probleme zu vermeiden.

Der erste Schritt in diesem Prozess besteht darin, eine neue Jutro-App zu erstellen und diese dann als Micro Frontend anzupassen. Dann verwenden Sie dieses neue Micro Frontend in einer anderen Jutro-App. In unserem Beispiel erstellen wir mit Jutro CLI eine zweite Jutro-App, die dann das neu erstellte Micro Frontend nutzt.

micro-frontends-Paket installieren​

Entweder instanziieren Sie eine neue Jutro-App oder Sie ändern eine bestehende Jutro-basierte Anwendung so, dass sie das Micro Frontend ist, das Sie einbetten möchten.

Installieren Sie das @jutro/micro-frontends-Paket in Ihrer Jutro-basierten Anwendung, damit Sie Zugriff auf die Micro Frontend-Funktionen haben:

npm i --save @jutro/micro-frontends@<your-jutro-version>
Important: Die Version des Pakets muss mit Ihren anderen Jutro Design System-Paketen übereinstimmen, wie z. B. @jutro/components.
Note:

Die @jutro/auth Abhängigkeit ist nun optional für @jutro/router und @jutro/components Pakete. Allerdings erfordert @jutro/micro-frontends package jetzt, dass @jutro/auth zu Ihren App-Abhängigkeiten hinzugefügt werden, um verwendet werden zu können.

Schritt 1: Eine Jutro-App als Micro Frontend verfügbar machen​

Nachdem Sie das Paket installiert haben, führen Sie die micro-frontend folgenden Schritte aus, um die eigenständige App in ein Micro Frontend zu konvertieren, das Sie in eine Shell-App einbetten können. Trotz der Umstellung auf ein Micro Frontend funktioniert die App weiterhin im Standalone-Modus.

  1. Stellen Sie im Micro Frontend-Repository sicher, dass src/indexAsync.js- und src/startApp.js-Dateien vorhanden und frei von Git-Konflikten sind. Wenn die Dateien nicht vorhanden sind, erstellen Sie sie manuell. Fügen Sie Folgendes in src/indexAsync.js hinzu:

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

  2. Ändern Sie in src/startApp.js die import der Funktion start in @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';
    /* ... */

    Sie müssen die Micro Frontend start-Funktion innerhalb der startApp-Funktion aufrufen:

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

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

  4. Starten Sie Ihre App:

npm i
PORT=3001 npm run start

Schritt 2: Ein Micro Frontend in eine Shell-App einbetten​

  1. Laden Sie Ihr Micro Frontend unter Verwendung der MicroFrontend-Komponente und durch Festlegen der Eigenschaft src. Diese Eigenschaft akzeptiert die App-ID des Micro Frontends zusammen mit der App-URL. Um mehr über diese Eigenschaft zu erfahren, lesen Sie den Abschnitt Micro Frontend API-Referenz.
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: Micro Frontends werden automatisch von Jutro-Fehlergrenzen umschlossen. Weitere Informationen finden Sie auf der Seite ErrorBoundary. Sie verwenden außerdem die standardmäßige Loader-Komponente.
  1. Starten Sie Ihre Shell-App:
npm i
PORT=3000 npm run start
Note: Wenn Ihr Micro Frontend die Größe innerhalb der Shell-App nicht korrekt anpasst, müssen Sie den folgenden Import in den Code Ihrer App einfügen: import iframe-resizer/js/iframeResizer.contentWindow.

src​

Sie können die Funktion getMicroFrontendSrc mit Ihrer Eigenschaft src verwenden, um die Quelle aus der Konfiguration zu erhalten. Diese Funktion ruft die App-ID und die URL Ihres Micro Frontends ab.

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

Wenn Sie dies tun, müssen Sie microFrontendsConfig in Ihrem src/config/config.json setzen.

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

Darüber hinaus können Sie die Eigenschaft src verwenden, ohne die ID in der Konfiguration festzulegen. Übergeben Sie einfach mfeAppId@uri. Beachten Sie, dass mfeAppId eindeutig sein muss. Sie wird in der Konfiguration Ihres Micro Frontends festgelegt.

Zum Beispiel:

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

Shell-App übergibt Konfigurationswerte an Micro Frontend​

Micro Frontends können nicht auf Shell-App-Konfigurationen zugreifen oder diese festlegen, da die Jutro-Konfigurationsspeicher und die @jutro/config-Paket-APIs in der Shell-App und den Micro Frontends voneinander isoliert sind.

Die Shell-App kann jedoch weiterhin die Anfangswerte für die Frontend-Konfigurationen bereitstellen. Die Shell-App kann auch die an die Jutro-Funktion übergebenen launchProps von Jutro start überschreiben. Sie können dies je nach Bedarf mit einer der folgenden Eigenschaften oder mit beiden erreichen:

  • configOverrides: Kurzform, falls Sie nur Jutro-Konfigurationen benötigen, die für die API getConfigValue verfügbar sein sollen.
Note: Diese Eigenschaften sind in der Eigenschaft jutro verschachtelt, um sie von den Eigenschaften zu trennen, die durch das Micro Frontend weitergegeben werden sollen.

Beispiel für die Verwendung der beiden Shell-App-Überschreibungseigenschaften:

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

Beispiel, wenn nur launchProps außer Kraft gesetzt werden sollen

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

Zurückgeben von Daten an die Shell-Anwendung​

Um Daten von einem Micro Frontend zurück an die Shell-Anwendung zu übergeben, können Sie eine Rückruffunktion von der Shell an das Micro Frontend übergeben. Wenn das Micro Frontend diesen Rückruf mit Argumenten aufruft, empfängt die Shell-Anwendung diese Argumente und kann die Daten nach Bedarf verarbeiten.

Note: Stellen Sie beim Übergeben von Daten sicher, dass Ihre benutzerdefinierten Rückrufe als Eigenschaften der MicroFrontend-Komponente übergeben werden und nicht in der jutro-Eigenschaft verschachtelt sind.

Die folgenden Abschnitte zeigen, wie Daten mit der Rückruffunktion vom Micro Frontend an die Shell-Anwendung übergeben werden:

Code im Micro Frontend​

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 in der Shell-App​

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

Einschränkungen bei Eigenschaften​

Im isolierten Modus müssen alle an Micro Frontends übergebenen Eigenschaften in JSON serialisierbar sein. Jutro unterstützt auch das Übergeben von Rückrufen, aber auch die an sie übergebenen Argumente müssen auf die gleiche Weise serialisierbar sein.

Weitere Informationen finden Sie unter The structured clone algorithm: supported types.

Richtig
<MicroFrontend
  jutro={{ mode: 'isolated' }}
  validProp="Strings are serializable"
  anotherValidProp={['apples', 'oranges', 'berries']}
  finallyAFunctionProp={() => {
    setOpen(false);
  }}
/>
Falsch
<MicroFrontend
  jutro={{ mode: 'isolated' }}
  invalidProp={<span>React Element are not serializable</span>}
  anotherInvalidProp={document.getElementById('DOM-nodes-are-not-serializable')}
/>

Authentifizierte Micro Frontends​

Micro Frontends sind so konzipiert, dass sie die von ihren Shell-Apps abgerufenen Authentifizierungstoken nutzen und so die Benutzererfahrung vereinfachen, indem sie einen einzigen Anmeldeablauf ermöglichen. Das bedeutet, dass Micro Frontends in den meisten Fällen keine Authentifizierungsabläufe durchführen müssen, was ihre Verwendung vereinfacht. Damit dieser Ansatz jedoch effektiv funktioniert, insbesondere bei der Verwendung von Guidewire Hub- und Server-APIs, müssen bestimmte Überlegungen angestellt werden.

Wenn von einem Micro Frontend erwartet wird, dass es Server-APIs aufruft, ist es entscheidend, dass das verwendete Token von Guidewire Hub ausgegeben wird. Diese APIs akzeptieren nur Token von Guidewire Hub, sodass die Verwendung eines Tokens aus einer anderen Quelle zu fehlgeschlagenen API-Aufrufen führt. Da JDP-Apps den Aussteller eines Tokens nicht validieren, führt die Übergabe eines Nicht-Guidewire-Hub-Tokens an ein Micro Frontend dazu, dass das Micro Frontend fälschlicherweise davon ausgeht, dass der Benutzer authentifiziert ist, und versucht, das Token zu verwenden, was zu Fehlern bei der Interaktion mit InsuranceSuite-APIs führt.

Wenn die Authentifizierungsintegration aktiviert ist, wird die AuthProviderStatic-Komponente im Micro Frontend verwendet, um Token aus der Shell zu füllen, ohne dass eine Authentifizierungslogik enthalten ist. Alle Versuche, login() oder logout() vom Micro Frontend aufzurufen, führen zu einem Fehler, da diese Aktionen in der Shell ausgeführt werden müssen.

In Szenarien, in denen das Micro Frontend in einen iframe eingebettet ist, gibt es zwei Optionen:

  1. (Empfohlen) Shell-App-Integration mit Guidewire Hub: Die Shell-App ruft das Authentifizierungstoken von Guidewire Hub ab und übergibt es an das Micro Frontend. Verwenden Sie für Jutro-Shell-Apps die Bibliothek @jutro/auth für die Authentifizierung. Für Apps von Drittanbietern integrieren Sie mithilfe des Okta Auth SDK .

  2. Micro Frontend-Integration mit Guidewire Hub: Wenn die Shell-App das Token vom IdP des Benutzers bezieht, muss unbedingt vermieden werden, dass dieses Token direkt an das Micro Frontend übergeben wird. Stattdessen muss das Micro Frontend einen eigenen Authentifizierungsprozess mithilfe der IdP-Sitzung des Benutzers initiieren. Bei diesem Prozess wird die vorhandene Sitzung mittels Cookies mit dem IdP des Kunden erkannt, die dann von Guidewire Hub zur Ausgabe eines neuen Tokens verwendet werden. Beachten Sie, dass diese Option bestimmte Auswirkungen auf die UX für die Benutzer hat, z. B. Popups, die ihnen angezeigt werden. Benutzer müssen auch ihre Browser-Popup-Blocker deaktivieren.

In beiden Fällen kann das Micro Frontend dieses von Guidewire Hub ausgegebene Token verwenden, um erfolgreich InsuranceSuite-APIs aufzurufen. Wenn die Authentifizierungsintegration deaktiviert ist, verwenden die Shell und das Micro Frontend unabhängige Token und initiieren separate Authentifizierungsabläufe. Der iframe öffnet ein Popup zur Authentifizierung und behält den Zustand der Shell bei, indem der Authentifizierungsablauf im Popup ausgeführt und anschließend geschlossen wird.

Note: Wenn Sie den nativen Okta-Authentifizierungs-Client verwenden und bereits eine Authentifizierungssitzung vorhanden ist, verwendet das Micro Frontend die vorhandene Sitzung, um ein Token abzurufen, ohne dass ein Popup-Fenster geöffnet wird. Dies ist jedoch nur möglich, wenn sich die Shell-App und das Micro Frontend in derselben Domäne befinden oder Cookies von Drittanbietern zugelassen sind. Wenn Cookies von Drittanbietern nicht zugelassen sind, wird das Popup nur kurz geöffnet.

Anforderungen​

Um sicherzustellen, dass beim Einbetten eines Micro Frontends mit aktivierter Authentifizierungsintegration ordnungsgemäß funktioniert, gibt es bestimmte Anforderungen an die sichere Kommunikation und Servicemitarbeiter. Ein Service Worker ist ein Hintergrundskript, das im Browser ausgeführt wird und Aufgaben wie die Verarbeitung von Authentifizierungsabläufen verwaltet.

Für die Entwicklung können Sie localhost mit HTTP verwenden, für die Produktion müssen Sie Bereitstellungen mit HTTPS verwenden. Diese Konfigurationen stellen sicher, dass Service Worker bei der Verarbeitung von Authentifizierungsabläufen ordnungsgemäß arbeiten. Wenn das Micro Frontend den Service Worker verwendet, müssen die Shell und das Micro Frontend am selben Standort bereitgestellt werden.

Die folgenden Konfigurationen gelten als sicher und ermöglichen es dem Service Worker, ordnungsgemäß zu funktionieren:

  • http://localhost – localhost wird bei HTTP als sicher behandelt, eine Ausnahme von typischen Sicherheitsrichtlinien.
  • https://example.com/app – Eine vollständig gültige HTTPS-URL.
  • https://localhost – Funktioniert mit einem vertrauenswürdigen, selbst signierten Zertifikat.
  • https://127.0.0.1 – Außerdem ist ein vertrauenswürdiges, selbst signiertes Zertifikat erforderlich.

In Fällen, in denen Sie eine localhost Shell verwenden, stellen Sie sicher, dass das bereitgestellte Micro Frontend die entsprechende frame-ancestors-Direktive in seinem Content-Security-Policy (CSP)-Header enthält, um die Einbettung zu ermöglichen.

Bei HTTPS-Setups localhost ohne gültiges Zertifikat funktionieren Service Worker nicht, sodass Jutro stattdessen den Sitzungsspeicher für die Authentifizierung verwendet. Standardmäßig deaktiviert Jutro den Service Worker und verwendet Sitzungsspeicher für localhost mit HTTPS-Apps. In diesem Szenario wird die folgende Warnung angezeigt: @jutro/auth Service Worker können nur für sichere Ursprünge registriert werden. Sie führen einen lokalen HTTPS-Server aus, daher wird der Sitzungsspeicher als Fallback verwendet. Wenn Sie Service Worker im lokalen HTTPS-Setup testen möchten, müssen Sie ihn explizit aktivieren, indem Sie die Variable REACT_APP_JUTRO_AUTH_HTTPS_LOCALHOST_SERVICE_WORKER=true .env hinzufügen oder zu reinem HTTP wechseln.

Bestimmte Konfigurationen verhindern, dass Service Worker registriert werden, was zu einer Unterbrechung der Authentifizierungsabläufe führen kann. Die Auswirkungen hängen davon ab, wie das Micro Frontend mit der Shell-App interagiert. Wenn das Micro Frontend seine Token aus der Shell bezieht und in der Shell die Authentifizierung aktiviert ist, z. B. wenn ein Service Worker verwendet wird, muss nur die Shell die Service Worker-Anforderungen erfüllen. Das Micro Frontend verwendet keinen Service Worker und muss diese Anforderungen nicht erfüllen. Wenn das Micro Frontend seine Token nicht von der Shell bezieht, unabhängig davon, ob in der Shell die Authentifizierung aktiviert ist oder nicht, muss das Micro Frontend einen Service Worker verwenden. In diesem Fall müssen sowohl das Micro Frontend als auch die Shell die Service Worker-Anforderungen erfüllen, um das ordnungsgemäße Funktionieren der Authentifizierungsabläufe zu gewährleisten.

Service Worker können nicht registriert werden, wenn entweder die Shell oder das Micro Frontend unter einer der folgenden Bedingungen ausgeführt wird, was zu einer Unterbrechung der Authentifizierungsabläufe führt:

  • http://127.0.0.1 – Nicht als sicherer Kontext betrachtet.
  • http://example.com/app – Eine ungesicherte HTTP-Verbindung.
  • https://localhost – Ohne vertrauenswürdiges Zertifikat.
  • https://example.com/app – Wenn das Zertifikat ungültig ist.

Anwendungsfälle​

Globalisierung​

Durch die Globalisierungsintegration werden Gebietsschema- und Spracheinstellungen in der Shell-App und in den Micro Frontends synchronisiert. Alle Änderungen an diesen Werten in der Shell oder in den Micro Frontends wirken sich sofort auf die andere App aus. Die Integration überträgt außerdem die standardmäßige Lokalisierungskonfiguration von der Shell auf die Micro Frontends. Das folgende Beispiel zeigt die Struktur der Lokalisierungskonfiguration:

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

Sie können die Integration deaktivieren, indem Sie die Eigenschaft integrateG11n auf falsesetzen. In diesem Fall verwenden die Micro Frontends ihre eigene Standardlokalisierungskonfiguration, und alle Änderungen an locale oder language wirken sich nicht auf andere Anwendungen aus.

Note: Die in configOverrides.localeSettings definierte Gebietsschemakonfiguration hat Vorrang vor Integrationswerten. Verwenden Sie dies, wenn Sie ein Gebietsschema für ein Micro Frontend angeben und sicherstellen möchten, dass es während der App-Laufzeit unverändert bleibt.

Die Standardwerte der Shell werden durch configOverrides.localeSettings überschrieben, wenn sie an eine Micro Frontend-Anwendung übergeben werden.

Das Micro Frontend verwendet configOverrides.localeSettings auch, wenn die Integration deaktiviert ist, und stellt nur Anfangswerte bereit. Wenn die Integration aktiviert ist, werden Änderungen an Gebietsschema oder Spracheinstellungen an andere Apps weitergegeben.

Das folgende Beispiel zeigt, wie Globalisierungseinstellungen in einem Micro Frontend eingerichtet werden:

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

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

Sie können die Modal-Integration aktivieren, indem Sie die Eigenschaft integrateModal auf truesetzen. Dadurch können Sie ein Modal im Micro Frontend auslösen, das dann in der Shell-App angezeigt wird.

Wenn integrateModal auf true festgelegt ist, werden die in einem eingebetteten Micro Frontend ausgelösten Modals in der Mitte des Shell-Fensters angezeigt und verwenden die Funktionen showAlert und showConfirm aus dem Modalkontext der Shell.

Wenn integrateModal auf false gesetzt ist, werden die von einem eingebetteten Micro Frontend ausgelösten Modals in der Mitte des Micro Frontend-Containers angezeigt.

<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: Benutzerdefinierte Modals, die durch Aufrufen der Funktion showModal aus dem von useModal() zurückgegebenen Modalkontext angezeigt werden, werden nicht integriert. Diese Einschränkung besteht, da das Senden von benutzerdefinierten React-Elementen nicht möglich ist. Daher ist die modale Integration auf Funktionen beschränkt, die nur serialisierbare Parameter verwenden. Entsprechend verhält es sich, wenn showModal in einem Micro Frontend ausgelöst wird, so, als ob integrateModal auf falsegesetzt wäre.

Weitere Informationen zu benutzerdefinierten Modals finden Sie in der Dokumentation zur Modalkomponente und auf der Seite zur Modalkomponente in Storybook .

Übersetzungen in Modals​

Wenn die Modals Übersetzungen enthalten, die nur im Micro Frontend verfügbar sind, und integrateModal auf true festgelegt ist, kann in der Shell-App nicht auf die Übersetzungen zugegriffen werden, wenn die App angezeigt wird. Für dieses Problem gibt es eine Reihe von Workarounds:

Inhalt vor dem Aufrufen der modalen Funktion übersetzen​

Sie können die Meldungen übersetzen, bevor Sie die modalen Funktionen mit der Funktion useTranslator() aus dem @jutro/locale-Paket aufrufen:

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>
    );
}
showModal anstelle von showConfirm verwenden​

Sie können showModal anstelle von showConfirm verwenden. Dabei tritt nicht das gleiche Problem wie bei showConfirm auf. Stattdessen wird showModal im Micro Frontend ausgeführt und das Modal direkt dort gerendet. Weitere Informationen finden Sie in der Dokumentation zur Modalkomponente.

Note: Bei allen MicroFrontend-Komponenten mit Kontextisolierung wird das Dialogfeld von showModal auf den iFrame des Micro Frontends beschränkt. Dies führt zu einem schlechteren Benutzererlebnis, beeinträchtigt die Barrierefreiheitsfunktionen und wird daher nicht empfohlen.
integrateModal auf false festlegen​

Sie können stattdessen integrateModal auf false festlegen und die Modal-Integration vermeiden.

Important: Das Festlegen von jutro: { integrateModal: false } für eine MicroFrontend-Komponente im Kontextfreigabemodus funktioniert visuell. Es beeinträchtigt jedoch die Barrierefreiheitsfunktionen und wird nicht empfohlen.

Verschachtelte Routernavigation​

Wenn Sie die <MicroFrontend>-Komponente im isolated-Modus verwenden, haben das Micro Frontend und die Shell-App einen unterschiedlichen Browsing-Kontext. Das bedeutet, dass der Speicherort und die Verlaufsobjekte des Browsers nicht vom Micro Frontend und der Shell-App gemeinsam genutzt werden.

Micro Frontends erkennen den Basisnamen ihres Routers automatisch anhand der URL der Shell-App in dem Moment, in dem sie gemountet werden. Wenn Sie einen expliziten Basisnamen festlegen möchten, können Sie dies tun, indem Sie die Eigenschaft jutro.router.basename an Ihr Micro Frontend übergeben.

Wenn Sie z. B. den folgenden Basisnamen angeben, bleibt der Shell-App-Pfad /welcome als Basispräfix für alle Micro Frontend-Pfade erhalten:

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

Die Router-Integration kann mit integrateRouter: falsedeaktiviert werden, wodurch Änderungen an der Adressleiste des Browsers und Aktualisierungen der Shell-Historie verhindert werden.

Integration von Popups​

Sie können die Popup-Integration aktivieren, indem Sie die Eigenschaft integrateToast auf truesetzen. Auf diese Weise können Sie eine Popupnachricht vom Micro Frontend auslösen, die von der Shell-App angezeigt wird. Wenn integrateToast auf true gesetzt ist, nutzen die Micro Frontends und die Shell-App denselben Popupanbieter, während das Festlegen auf false jedem Micro Frontend und jeder Shell-App einen eigenen unabhängigen Anbieter ermöglicht.

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

Verwendung mit benutzerdefiniertem Loader und Fehlergrenze​

Beispiele für die Verwendung der Micro Frontend-Komponente mit benutzerdefinierten Eigenschaften:

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: Wenn Sie benutzerdefinierte Loader und eigene Fehlergrenzen verwenden, überschreiben Sie die Basiskonfiguration für Rendering und Fehlerbehandlung.

Dies kann zu Laufzeitproblemen führen.

Anzeigen einer Kopf- oder Fußzeile innerhalb des Micro Frontends​

Die Werte footer und header eines Micro Frontends, das mit MicroFrontend component in context isolation mode erstellt wurde, sind standardmäßig ausgeblendet, obwohl subHeader an bestimmten Messpunkten weiterhin sichtbar ist. Um diese Elemente in Ihrem Micro Frontend anzuzeigen, müssen Sie sie innerhalb des Micro Frontends zusammen mit seinem Inhalt mithilfe der Komponenten Grid oder Flex rendern. Das folgende Beispiel zeigt eine Methode zum Rendern der Fußzeile:

// 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: Die Footer-Komponente aus der Jutro-App-Vorlage verfügt standardmäßig nicht über Styling, sondern erbt das Styling über die Eigenschaft className, die intern von der intern aus der Grundriss-Komponente übergeben wird. Es gibt keine andere Möglichkeit, auf Grundriss-Fußzeilenstile zuzugreifen, daher müssen Sie die Fußzeile selbst gestalten.

iframe-Attribute​

Es ist möglich, zusätzliche Attribute für Micro Frontends zu übergeben, die im isolierten Modus oder im SDK eingebettet sind. Dadurch ist es möglich, verschiedene Browserfunktionen zu aktivieren. Einträge aus der Eigenschaft iframeAttributes werden dem iframe-HTML-Element hinzugefügt. Nur Eigenschaften allow, referrerpolicy und sandbox sind zulässig. Weitere Informationen zu diesen Eigenschaften finden Sie in der Micro Frontend API-Referenz.

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

Erneutes Laden eines Micro Frontends​

Sie können ein Micro Frontend () => window.location.reload() neu laden, indem Sie den benutzerdefinierten Rückruf aus der Shell-App übergeben. Das folgende Beispiel zeigt, wie sie in einer Schaltfläche implementiert wird:

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

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