Angular Page Builder mit GrapesJS

Der Standard-Editor: Leinwand, Blöcke, Layer-Baum, Style-Manager und Geräte-Switcher. Das ist das Fundament, von dem aus du startest, bevor du einen eigenen Block hinzufügst.

Einen Page Builder zu bauen erfordert weit mehr als nur ein paar Angular-Komponenten. Ein produktionsbereiter visueller Editor benötigt all diese Komponenten, bevor jemand eine Seite damit ausliefern kann:

• Drag & Drop
• Leinwand
• Komponenten
• Blöcke
• Schichten
• Stile
• Responsive Bearbeitung
• Vermögensverwaltung
• Vorlagen
• Projektlagerung
• Export
• Verlagswesen

GrapesJS bietet die visuelle Bearbeitungsgrundlage für den Großteil dieser Liste, sodass Ihre Angular-Anwendung ihr Budget stattdessen für Ihr Produkt und Ihre Geschäftslogik ausgeben kann. Die letzten beiden – wo Projekte gespeichert werden und wie Seiten live werden – bleiben bei dir, weil sie die Teile sind, die zu deiner Infrastruktur passen müssen.

GrapesJS Core ist Open Source unter der BSD-3-Clause-Lizenz, Version 0.23.6, ohne Lizenzgebühr in irgendeinem Maßstab.

Der Editor ist eine Möglichkeit innerhalb deiner Anwendung, kein Ersatz dafür. Alles oberhalb der Bearbeitungsebene bleibt genau dort, wo die Angular-Teams es bereits platziert haben.

1. 01

   Angular-Anwendung

   Alles, was Ihr Produkt zu Ihrem macht, bleibt unverändert.

   • Authentifizierung
   • Nutzer
   • Abrechnung
   • Routing
   • Geschäftslogik
   ↓
2. 02

   Visueller Seitengenerator

   Eine lazy-loaded Route, eine Komponente, die den Container besitzt, und ein Service, der die Editor-Instanz besitzt.

   • Editor-Route
   • Editor-Komponente
   • Redaktionsdienst
   ↓
3. 03

   GrapesJS

   Die visuelle Bearbeitungs-Engine, die innerhalb des Containers läuft, den deine Komponente bereitstellt.

   • Leinwand
   • Komponenten
   • Blöcke
   • Schichten
   • Stile
   • Vermögenswerte
   • Kommandos
   ↓
4. 04

   Dein Backend

   Wo Projektdaten, Uploads und veröffentlichte Ausgaben tatsächlich gespeichert sind.

   • Dein API
   • Deine Datenbank
   • Dateispeicherung

Angular besitzt deine Anwendung. GrapesJS treibt die visuelle Bearbeitungsebene an.

Nichts im oberen oder unteren Bereich wird vom Editor bereitgestellt. Diese Grenze hält die Integration flach genug, um später entfernt zu werden – der Editor wird nie zu dem, worum dein Produkt aufgebaut ist.

Ein generischer Website-Builder ist selten das Produkt, das jemand möchte. Jede Ebene des Editors kann stattdessen durch etwas ersetzt werden, das zu deiner Anwendung passt.

// Your content model, not a generic website element.
editor.Components.addType('pricing-table', {
  isComponent: (el) => el.dataset?.gjsType === 'pricing-table',
  model: {
    defaults: {
      tagName: 'section',
      droppable: false,
      traits: ['plan', 'currency', 'billingPeriod'],
    },
  },
});

editor.Blocks.add('pricing-table', {
  label: 'Pricing',
  category: 'Your design system',
  content: { type: 'pricing-table' },
});

Der Unterschied zwischen einem Editor, den viele benutzen, und einem, den sie aufgeben, ist meist das, was am ersten Tag in der Palette ist.

GrapesJS serialisiert ein Projekt an JSON und übergibt es an einen Speicheradapter. Was dieser Adapter macht, liegt ganz bei dir.

editor.Storage.add('angular-backend', {
  async load() {
    return firstValueFrom(this.http.get(`/api/pages/${this.pageId}`));
  },
  async store(data) {
    return firstValueFrom(this.http.put(`/api/pages/${this.pageId}`, data));
  },
});

grapesjs.init({
  container,
  storageManager: { type: 'angular-backend', autosave: true, stepsBeforeSave: 5 },
});

• Projektdaten

  Komponenten, Stile, Seiten und Assets serialisieren sich zu einem JSON-Dokument, das du in jeder Spalte oder Sammlung speichern kannst.

• Autosave

  Der Speichermanager kann nach einer konfigurierbaren Anzahl von Änderungen speichern, nicht nur bei einer expliziten Aktion.

• Fernspeicherung

  Registrieren Sie einen benutzerdefinierten Adapter und routen Sie über Angular's HttpClient, mit eigenen Abfang- und Authentifizierungsheadern.

• Versionierung

  Da jeder Speicherstand ein Dokument ist, ist das Führen des Verlaufs eine Entscheidung im Backend – der Editor muss nicht wissen, dass es passiert ist.

• HTML/CSS-Ausgang

  Exportiere das gerenderte Markup zusammen mit dem Projekt-JSON, wenn dein Lieferpfad eine statische Ausgabe statt eines erneuten Renderings benötigt.

• Verlagswesen

  Eine veröffentlichte Seite ist ein separater Datensatz mit eigenem Lebenszyklus. Halte sie getrennt vom Entwurf, auf den der Editor schreibt.

Du bestimmst, wo Projektdaten gespeichert werden.

Authoring und Publishing sind unterschiedliche Probleme mit unterschiedlichen Fehlermodi. Der Editor löst das erste; das zweite bleibt in deiner Infrastruktur, wo dein Caching, deine Berechtigungen und Rollbacks bereits liegen.

Wohin veröffentlichte Ausgaben gelangen können

• CMS

  Schreiben Sie die Ergebnisse zurück in das Inhaltssystem, das Ihre Organisation bereits betreibt.

• REST API

  Poste das Projekt oder das gerenderte Markup auf einen Endpunkt, der Validierung und Berechtigungen besitzt.

• Statische Veröffentlichung

  Rendere Seiten zum Zeitpunkt der Veröffentlichung in Dateien, sodass die Live-Seite keinen Teil der Laufzeit des Editors enthält.

• Benutzerdefiniertes Backend

  Speichere, transformieren und bereitstellen Sie die Ausgabe über denselben Pfad, den Ihre Anwendung bereits zur Bereitstellung ihrer Seiten verwendet.

• CDN

  Drücke veröffentlichte Assets und Markup an den Rand, wobei du die Cache-Invalidierung kontrollierst.

• Benutzerdefinierte Bereitstellung

  Lösen Sie Ihre bestehende Build- oder Deployment-Pipeline aus der Veröffentlichungsaktion aus.

GrapesJS übernimmt das Authoring. Deine Infrastruktur kann das Veröffentlichen übernehmen.

Eine Bereitstellung Ihrer Angular-Anwendung, ein Editor und eine separate Seite für jeden Kunden darin.

Nichts am Editor muss so aussehen wie der Editor. Jede Oberfläche, die ein Nutzer berührt, ist konfigurierbar, austauschbar oder entfernbar.

• Dein Logo anstelle des Chroms des Editors
• Deine Farbmarker, kein Drittpartei-Thema
• Benutzerdefinierte Panels oder dein eigenes Angular UI, das den Editor durch Befehle steuert
• Nur die Blöcke, die dein Produkt unterstützt
• Vorlagen, die aus deinem Designsystem stammen
• Dein Vokabular – Abschnitte, Module, Layouts, was auch immer deine Nutzer bereits sagen
• Rollen, die entscheiden, wer bearbeiten, wer veröffentlichen darf und wer nur kommentieren darf
• Auf dem Server durchgesetzte Berechtigungen, die sich im UI widerspiegeln

Machen Sie einen visuellen Editor zu einem nativen Teil Ihres Angular-Produkts.

Die Kurzfassung, in vier Schritten. Der vollständige Leitfaden – Lebenszyklusdetails, Wrapper, zonenlose Änderungserkennung, Produktionsbedenken – lebt auf eigener Seite und geht viel weiter als das.

1. 1

   Installation

   Füge den Editor deiner Anwendung hinzu. Es ist ein schlichtes npm-Paket ohne Angular-spezifischen Build-Schritt.

2. 2

   Erstellen Sie einen Editor-Service

   Halte die Editor-Instanz in einem injizierbaren Service, damit die Komponente dünn bleibt und die Instanz einfach zu teilen, mocken und zerlegen ist.

3. 3

   Initialisieren in ngAfterViewInit

   Das Container-Element muss im DOM sein, bevor der Editor erstellt wird, da GrapesJS es sofort misst.

4. 4

   Zerstöre korrekt in ngOnDestroy

   Ruf destroy, wenn die Route links ist. Ohne sie behält der Editor seine DOM-Listener und die nächste Navigation leakt eine Instance.

import { Injectable, NgZone, inject } from '@angular/core';
import grapesjs, { type Editor } from 'grapesjs';

@Injectable({ providedIn: 'root' })
export class PageBuilderService {
  private readonly zone = inject(NgZone);
  private editor?: Editor;

  create(container: HTMLElement): Editor {
    // GrapesJS binds its own DOM listeners to the canvas. Creating it outside
    // Angular keeps every drag frame from scheduling change detection.
    this.editor = this.zone.runOutsideAngular(() =>
      grapesjs.init({
        container,
        height: '100%',
        fromElement: false,
        storageManager: false,
      })
    );

    return this.editor;
  }

  destroy(): void {
    this.editor?.destroy();
    this.editor = undefined;
  }
}

import {
  AfterViewInit,
  Component,
  ElementRef,
  OnDestroy,
  inject,
  viewChild,
} from '@angular/core';
import { PageBuilderService } from './page-builder.service';

@Component({
  selector: 'app-page-builder',
  standalone: true,
  template: '<div #canvas class="builder"></div>',
  styles: '.builder { height: 100vh; }',
})
export class PageBuilderComponent implements AfterViewInit, OnDestroy {
  private readonly builder = inject(PageBuilderService);
  private readonly canvas = viewChild.required<ElementRef<HTMLElement>>('canvas');

  ngAfterViewInit(): void {
    // The container has to be in the DOM first: GrapesJS measures it on init.
    this.builder.create(this.canvas().nativeElement);
  }

  ngOnDestroy(): void {
    // Without this the editor keeps its listeners after the route changes.
    this.builder.destroy();
  }
}

GrapesJS sendet eigene Ereignisse, und diese Ereignisse stammen nicht aus Angular. Die Koordination der beiden sind ein paar Zeilen, aber das Überspringen führt zu den beiden Fehlern, die jede Integration zuerst trifft.

editor.on('storage:end:store', () => {
  // Editor events fire outside Angular because the editor was created there.
  // Re-enter the zone before touching state the template renders.
  this.zone.run(() => this.lastSavedAt.set(new Date()));
});

Erstelle den Editor innerhalb von runOutsideAngular, sodass die Canvas-Interaktion nicht bei jedem Frame die Änderungserkennung plant, und tritt dann in die Zone in den wenigen Ereignishandlern ein, die tatsächlich den Status aktualisieren, die deine Vorlage rendert. Bei einer zonenlosen Anwendung aktualisieren dieselben Handler stattdessen die Signale, und der äußere Wrapper wird nicht mehr benötigt.

GrapesJS benötigt einen Browser DOM. Bei Angular SSR oder Angular Universal bedeutet das, dass der Editor nur im Browser erstellt wird – die Route um ihn herum wird auf dem Server weiterhin wie gewohnt gerendert.

import { PLATFORM_ID, inject } from '@angular/core';
import { isPlatformBrowser } from '@angular/common';

export class PageBuilderComponent implements AfterViewInit {
  private readonly isBrowser = isPlatformBrowser(inject(PLATFORM_ID));

  ngAfterViewInit(): void {
    // There is no DOM on the server and GrapesJS needs one, so the editor is
    // created in the browser only. The rest of the route still renders on the
    // server as usual.
    if (!this.isBrowser) return;
    this.builder.create(this.canvas().nativeElement);
  }
}

Die Integration ist gewöhnlicher Angular-Code, was das Wichtigste ist, das darüber zu sagen.

• TypeScript-freundlich

  Der Editor liefert eigene Typdefinitionen, sodass die Instanz, ihre Konfiguration und ihre Ereignisse am Aufrufstandort getippt werden.

• Angular-Lebenszyklus

  Erstellung und Zerlegung hängt von ngAfterViewInit und ngOnDestroy ab – kein manuelles Bootstrapping außerhalb des Komponentenbaums.

• AOT-kompatibel

  Nichts in der Integration hängt von der Laufzeit-Template-Kompilierung ab, daher baut sich die Editor-Route wie jede andere lazy-loaded-Route.

• Browser-only Initialisierung

  Wo SSR im Spiel ist, ist nur die Editor-Erstellung browser-geschützt; der Rest der Komponente kompiliert und rendert normal.

Die Engine bietet dir die Bearbeitungsfläche. Alles, was ein bestimmtes Produkt darüber benötigt – die Blockpalette, das Template-System, Rich Text, Persistenz, der Exit-Weg zur Produktion – ist der Punkt, an dem GJS.Market-Plugins ins Spiel kommen. Jede untenstehende Präsentation ist ein echtes Produkt, bepreist wie angegeben.

Blöcke

Problem: Ein frischer Editor hat eine leere Palette, und niemand baut eine Seite aus einem nackten <div>.

Durchstöbern Sie diese Kategorie

Blöcke

Plugin Basic Blocks

Die Startpalette: Spalten, Text, Bilder, Links und Video, damit die Leinwand am ersten Tag nutzbar ist.

KostenlosView-Plugin

Blöcke

Grapesjs Tailwind

Tailwind-basierte Blöcke, sodass Seiten, die Nutzer erstellen, zu einem Utility-Design-System passen, das du bereits nutzt.

KostenlosView-Plugin

Blöcke

GrapesJS Bootstrap v5 Blocks

Bootstrap-5-Gitter- und Komponentenblöcke für Teams, deren Designsystem bereits Bootstrap ist.

KostenlosView-Plugin

Blöcke

Super Header for GrapesJS

Ein Header wurde einmal bearbeitet und auf jeder Seite wiederverwendet, anstatt dass Kopien auseinanderdrifteten.

39,00 $View-Plugin

Vorlagen & Seiten

Problem: Nutzer brauchen einen Anfang, und mehrseitige Projekte benötigen einen Manager, den der Editor nicht ausliefert.

Durchstöbern Sie diese Kategorie

Vorlagen

Templates Manager

Eine Vorlagenbibliothek im Editor, sodass eine neue Seite von einem fertigen Layout beginnt.

39,00 $View-Plugin

Seiten

Pages Manager

Mehrseitige Projekte mit einer Seitenliste, sodass ein Builder eine Website statt eines einzelnen Dokuments verwaltet.

25,00 $View-Plugin

Blöcke

Users Blocks

Ermöglicht es Nutzern, ihre eigenen Abschnitte als wiederverwendbare Blöcke zu speichern – deine Palette wächst, ohne dass du etwas aussendest.

59,00 $View-Plugin

Projekte

Grapesjs Project Manager

Projektstöbern und -management rund um den Editor – für Teams, die an mehr als einer Sache gleichzeitig arbeiten.

KostenlosView-Plugin

Text & Formulare

Problem: Jeder geht davon aus, dass reicher Text und funktionierende Formulare eingebaut sind. Keines von beiden ist es, abgesehen von den Basics.

Durchstöbern Sie diese Kategorie

Formulare

Plugin Forms

Formular-Komponenten mit Eingaben, Auswahlen und Validierung von traits, bereit zur Einsendung an Ihre Endpunkte.

KostenlosView-Plugin

RTE

GrapesJS Inline Text Editor — Compatible with CKEditor 5

Ersetzt den eingebauten Rich-Text-Editor durch CKEditor 5 für Teams, die ernsthafte Textbearbeitung benötigen.

69,00 $View-Plugin

RTE

TinyMCE 8 Inline Text Editor

Dasselbe gilt für TinyMCE 6 – jedem bekannt, der von einem traditionellen CMS kommt.

69,00 $View-Plugin

RTE

Grapesjs RTE Extensions

Zusätzliche Formatierungssteuerungen im Standard-Rich-Text-Editor, ohne eine Drittanbieterabhängigkeit hinzuzufügen.

KostenlosView-Plugin

Speicher und Ausgabe

Problem: Der Prototyp, der nie etwas durchgehalten hat, ist der, der nie ausgeliefert wurde.

Durchstöbern Sie diese Kategorie

Lagerung

IndexedDB Storage

Lokale Persistenz im Browser: nützlich für Entwürfe, Offline-Bearbeitung und Vorschauumgebungen.

KostenlosView-Plugin

Lagerung

Directus Storage

Lagert Projekte in Directus, wenn ein headless Backend bereits Teil deines Stacks ist.

KostenlosView-Plugin

Export

Export Zip

Lädt eine Seite als ZIP von HTML, CSS und Assets herunter – der einfachste mögliche Exportweg.

KostenlosView-Plugin

Verlagswesen

Grapesjs Netlify

Veröffentlicht direkt auf Netlify für Produkte, deren Ausgabe eine gehostete, statische Seite ist.

KostenlosView-Plugin

Beide Säulen enden mit einem funktionierenden Bauunternehmer. Sie unterscheiden sich darin, wie viel davon man in zwei Jahren noch instand hält.

GrapesJS bietet die visuelle Bearbeitungsgrundlage. GJS.Market-Plugins ermöglichen es dir, deinen Builder um zusätzliche Funktionen zu erweitern, anstatt jede Funktion intern zu bauen.

Nutze Angular für deine Anwendung und GrapesJS für das visuelle Bearbeitungserlebnis. Füge eigene Komponenten, Blöcke, Vorlagen, Speicher- und Veröffentlichungsworkflow hinzu – und erweitere den Builder dann mit GJS.Market-Plugins, wenn du mehr brauchst.