Visual-Editing für Ihre Next.js-App und andere Frontends

Das neue External SPA-Feature in Magnolia 6.2.14 ermöglicht es Ihnen, Ihre Anwendungen in Magnolias Visual SPA Editor zu bearbeiten, während Sie Ihr SPA auf einem beliebigen Server Ihrer Wahl hosten und die Vorteile der beliebten Meta-Frameworks wie Next, Gatsby, Nuxt oder Scully nutzen.

Um eine SPA oder andere Frontend-Projekte im Visual SPA Editor, auch Magnolia Page Editor genannt, zu bearbeiten, mussten Sie bisher eine Kopie Ihres Frontends auf Magnolia hosten. Jetzt können Sie Ihr Frontend auf einem beliebigen Server hosten. Das macht die Entwicklung viel komfortabler und ermöglicht die Arbeit mit diesen Meta-Frameworks.

Eine ähnliche Funktionalität war bereits mit der SPA Renderer Extended-Erweiterung auf unserem Marketplace verfügbar. Wenn Sie die Erweiterung verwenden, empfehle ich Ihnen, so schnell wie möglich ein Upgrade auf die Produktfunktion vorzunehmen.

Während es bisher möglich war, Ihre Produktionsanwendung überall zu hosten, mussten Sie Ihre SPA nach jedem Update in ein Magnolia Light Module einbauen und bereitstellen, um ihre Seiten mit dem Visual Editor von Magnolia bearbeiten zu können. Jetzt können Sie Ihre SPA wie gewohnt entwickeln - typischerweise auf dem Dev-Server für das React-, Vue- oder Angular-Projekt - und Magnolia einfach auf die URL verweisen, die Ihr Frontend hostet. Dadurch entfallen die zusätzlichen Build- und Deploy-Schritte während der Entwicklung.

Die Änderungen, die Sie an Ihrer SPA vornehmen, werden sofort im Magnolia Page Editor angezeigt, ohne dass Sie die Seite neu laden müssen. Ja, sogar Hot Module Repleacement (HMR) funktioniert.

Schauen wir uns kurz an, wie dies konfiguriert ist.

Zuvor mussten Sie ein templateScript in Ihrer Seitenvorlagendefinition angeben, um dem Seiteneditor mitzuteilen, woher er das JS-Bündel laden soll.

Datei: templates/pages/basic.yaml

Jetzt können Sie stattdessen eine baseUrl3 und ein routeTemplate angeben. Zusammen geben sie die URL an, die der Seiteneditor lädt, basierend auf der Seite, die gerade in der Seiten-App bearbeitet wird.

Die baseUrl gibt, Sie ahnen es, die Basis-URL Ihres Frontends an. Das routeTemplate legt den Rest der URL fest. Sie können auch Eigenschaften hinzufügen, die in die URL interpoliert werden sollen, zum Beispiel {{path}} und {language}.

Datei: templates/pages/basic.yaml

Beispiel: Für eine Seite mit dem Pfad '/great-scott' würde der Seiteneditor die URL laden: http://localhost:3000/great-scott?lang=en

Für weitere Informationen konsultieren Sie bitte unsere Dokumentation.

Und wenn Sie es gleich ausprobieren möchten, sehen Sie sich unsere SPA-Demoprojekte für React, Vue und Angular an.

Das frühere Setup bedeutete, dass einige Projekte zwei Versionen der gleichen Anwendung hatten, eine für die Bearbeitung und eine für die Produktion. Nun, da Sie die Front-End-App, die vom Magnolia Page Editor verwendet wird, überall hosten können, benötigen Sie nur noch eine Version Ihrer App.

Natürlich können Sie Gründe haben, zwei getrennte Anwendungen für die Bearbeitung und die Produktion zu haben, aber selbst dann wird Ihr Leben einfacher, weil beide Versionen mit demselben Prozess bereitgestellt werden können - oder mit einem beliebigen Prozess Ihrer Wahl. Sie könnten beispielsweise von Netlify oder einem anderen CI/CD-System jedes Mal erstellt und bereitgestellt werden, wenn Sie Code in Ihr Git-Repository stellen.

Während viele Frontend-Projekte aus einem einzigen JavaScript-Bündel bestehen, das auf einem einfachen Dateiserver bereitgestellt wird und Inhalte über REST lädt, nutzen komplexere Projekte zunehmend die Vorteile des Hostings ihrer Frontends auf einem speziellen Server. Dies wird manchmal als "Backend for Frontend" (BFF) bezeichnet.

Die spezialisierten Entwicklungsserver für Front-End-Meta-Frameworks wie Next, Gatsby, Nuxt und Scully können:

SSG und SSR haben Vorteile für SEO, Suchindexierung und die Generierung von Vorschaubildern in sozialen Netzwerken und Tools wie Slack.

Da der Seiteneditor Ihre Anwendung nun von jeder URL laden kann, können Sie ihn mit jedem dieser spezialisierten Server verwenden.

Möchten Sie es in Action sehen? Unser erstes Meta-Framework-Demoprojekt ist jetzt verfügbar und verwendet Next.js. Werfen Sie einen Blick in die README in unserem Repository für Demoprojekte.

Sie werden feststellen, dass wir zwei Anwendungen für Next.js enthalten: eine für SSR und eine für SSG. Natürlich sind dies nur einfache Beispiele. Je nach Ihren Bedürfnissen werden Sie wahrscheinlich beide Techniken miteinander kombinieren.

Für SSR und SSG ist es wichtig zu beachten, dass einige JS auf dem Server statt im Browser laufen. Um dies in Magnolias Bibliothek react-editor zu berücksichtigen, müssen Sie die Variable global.mgnlInPageEditor in Ihrem Code setzen.

Da Sie keinen Zugriff auf Browser-Objekte haben, können Sie auch das Next.js-Objekt context in Ihrem Code verwenden, zum Beispiel context.resolvedUrl anstelle von window.location.pathname

Die wichtigsten Teile der SSR-Implementierung finden Sie in der Datei /pages/[[...pathname]].js.

getServerSideProps läuft auf dem Server und holt den Seiteninhalt. useEffect() führt Code im Browser aus. In der exportierten Pathname Komponente ruft useEffect die templateAnnotations ab, sobald die Seite geladen ist. Dies ist wichtig, um Magnolias grüne Bearbeitungsleisten im Seiteneditor anzuzeigen.

Moment, SSG? Wie kann man eine Seite einer statischen Website bearbeiten? Das Next.js-Framework hat mit seinem Vorschaumodus eine eingebaute Lösung für dieses Problem. Das Schlüsselkonzept ist: "Wenn Sie eine Seite anfordern, die getStaticProps mit gesetzten Vorschaumodus-Cookies hat, dann wird getStaticProps zur Anforderungszeit (statt zur Erstellungszeit) aufgerufen."

Bei der Generierung der statischen Site wird also getStaticProps für jede Seite ausgeführt. Bei der Bearbeitung der Seite im Magnolia-Seiteneditor wird getStaticProps jedoch dynamisch auf der aktuellen Seite ausgeführt. So können Benutzer eine Seite bearbeiten und sofort das Ergebnis ihrer Änderung sehen. Um diese Änderung in die Produktion zu übertragen, ist ein neuer Build und ein Push auf den Server oder das CDN erforderlich, z.B. über einen Webhook.

In unserem SSG-Demoprojekt ist /pages/[[...pathname]].js auch die Schlüsseldatei. Sie funktioniert auf die gleiche Weise wie SSR, wobei getStaticProps die gleichen Aufgaben übernimmt wie getServerSideProps im SSR-Modus. Die sogenannte "Vorschau-API" wird in /pages/api/preview.js eingerichtet.

Der Vorschaumodus erwartet, dass die App mit einem bestimmten slug query string aufgerufen wird. Dies kann einfach in der Definition der Seitenvorlage mit dem Parameter routeTemplate erreicht werden:

Wenn Sie an Next.js interessiert sind, schauen Sie sich die SSR- und SSG-Demoprojekte an. Sie können wahrscheinlich ein Next.js-Projekt in 15 Minuten zum Laufen bringen.

Wenn Sie bereits den Visual SPA Editor in Magnolia verwenden, empfehle ich Ihnen, den neuen Ansatz auszuprobieren. Sie werden es lieben, gegen den Dev-Server Ihres Frameworks zu entwickeln. Sie müssen nur die Eigenschaften baseUrl und routeTemplate zu Ihren Seitenvorlagendefinitionen hinzufügen und Sie sind im Handumdrehen startklar.