GrapesJS Angular:Baue einen Visual Editor mit Angular

Der Standard-GrapesJS-Build – der Editor, den du von 'GrapesJS.init()' mit dem Standard-Preset bekommst, bevor ein Plugin hinzugefügt wird. Ziehe einen Block aus dem rechten Panel, wähle ihn aus und bearbeite seine Typografie sowie Abstände im Style-Manager.

GrapesJS ist die visuelle Bearbeitungs-Engine. Angular ist das Anwendungsframework. Fast jedes Integrationsproblem, auf das Leute stoßen, entstehen daher, dass man erwartet, dass einer von ihnen die Arbeit des anderen erledigt, daher lohnt es sich, die Grenze zwischen ihnen explizit zu benennen.

Angular ist deine Anwendung. GrapesJS ist deine visuelle Bearbeitungsmaschine.

Eine Abhängigkeit und ein Stylesheet. GrapesJS liefert sein eigenes CSS aus, und ohne es mountet der Editor ein, rendert aber als unstyletes Markup – was der häufigste Grund ist, warum eine erste Integration kaputt aussieht.

1 — Addiere die Abhängigkeit

2 — Stylesheet registrieren

// angular.json → projects.<app>.architect.build.options
{
  "styles": [
    "src/styles.css",
    "node_modules/grapesjs/dist/css/grapes.min.css"
  ]
}

Das Registrieren des Stylesheets in angular.json wendet es global an. Wenn der Editor auf einer faul geladenen Route lebt und du nicht überall für CSS bezahlen möchtest, importiere es stattdessen im eigenen Stylesheet der Editor-Komponente.

Bevor du die Komponente schreibst

Drei Dateien, nichts generiert, nichts versteckt. Kopieren Sie sie in eine Angular-Anwendung und Sie haben einen funktionierenden visuellen Editor auf einer Route. Alles später auf dieser Seite – Speicher, Assets, benutzerdefinierte Komponenten, Plugins – ist eine Ergänzung zu dieser Komponente, keine Neuschreibung davon.

// editor.component.ts
import {
  AfterViewInit,
  Component,
  ElementRef,
  OnDestroy,
  ViewChild,
} from '@angular/core';
import grapesjs, { type Editor } from 'grapesjs';

@Component({
  selector: 'app-editor',
  templateUrl: './editor.component.html',
  styleUrl: './editor.component.css',
})
export class EditorComponent implements AfterViewInit, OnDestroy {
  // Resolved by the time ngAfterViewInit runs — that is the whole reason
  // initialisation lives there and not in ngOnInit.
  @ViewChild('editorHost') private host!: ElementRef<HTMLDivElement>;

  private editor?: Editor;

  ngAfterViewInit(): void {
    this.editor = grapesjs.init({
      container: this.host.nativeElement,
      height: '100%',
      width: 'auto',
      fromElement: false,
      // No persistence yet. Wire your own API before shipping — see Storage.
      storageManager: false,
      blockManager: {
        blocks: [
          {
            id: 'section',
            label: 'Section',
            category: 'Layout',
            content: '<section class="section"><h2>Headline</h2></section>',
          },
          {
            id: 'text',
            label: 'Text',
            category: 'Basic',
            content: { type: 'text', content: 'Edit me' },
          },
          { id: 'image', label: 'Image', category: 'Basic', content: { type: 'image' } },
        ],
      },
    });
  }

  ngOnDestroy(): void {
    // GrapesJS owns DOM nodes, document listeners and an undo stack. Angular
    // removes the host element; only destroy() releases the rest.
    this.editor?.destroy();
    this.editor = undefined;
  }
}

<!-- editor.component.html -->
<!-- GrapesJS takes this element over completely. Do not render Angular
     content inside it — the editor owns everything below #editorHost. -->
<div class="editor-shell">
  <div #editorHost class="editor-host"></div>
</div>

/* editor.component.css */
.editor-shell {
  display: block;
  block-size: 100dvh;
}

/* GrapesJS measures its container at init. A host with no resolved height
   produces an editor that mounts successfully and renders nothing. */
.editor-host {
  block-size: 100%;
}

Das ist die gesamte Integration. Die Teile, die es wert sind, noch einmal durchzulesen, sind die beiden Lebenszyklus-Hooks: die Initialisierung in ngAfterViewInit, weil der Container zuerst existieren muss, und destroy() in ngOnDestroy, weil das Entfernen des Hostelements durch Angular nicht das an das Dokument angehängte GrapesJS freigibt.

Lade den Editor auf seiner eigenen Route

Der Editor ist das schwerste in den meisten Anwendungen, die einen enthalten. Wenn man ihn hinter eine faul geladene Route legt, bleibt er für jeden Nutzer, der ihn nie öffnet, aus dem ursprünglichen Bundle heraus.

// app.routes.ts — the editor is the heaviest route in the app. Load it last.
import type { Routes } from '@angular/router';

export const routes: Routes = [
  { path: '', loadComponent: () => import('./home/home.component').then((m) => m.HomeComponent) },
  {
    path: 'pages/:id/edit',
    loadComponent: () => import('./editor/editor.component').then((m) => m.EditorComponent),
  },
];

Die Lebensdauer des Editors muss an die der Komponenten gebunden sein. Vier Teile übernehmen diese Arbeit, und jedes von ihnen versagt auf erkennbare Weise, wenn es fehlt.

GrapesJS verbindet eine große Anzahl von Zuhörern mit seiner Canvas und feuert sie kontinuierlich, während eine Komponente gezogen oder verkleinert wird. In einer zonenbasierten Angular-Anwendung plant jeder dieser Zuhörer einen Änderungserkennungsdurchlauf, obwohl sich in Ihrem Komponentenbaum nichts geändert hat.

// editor.component.ts (excerpt)
import { Component, NgZone, inject, signal } from '@angular/core';

export class EditorComponent {
  private readonly zone = inject(NgZone);

  readonly selectedTag = signal('');
  readonly savedAt = signal<Date | null>(null);

  private mount(host: HTMLElement): void {
    // The canvas fires pointer events continuously while a block is being
    // dragged. Creating the editor outside the zone keeps those from
    // scheduling a change-detection pass on every frame.
    this.zone.runOutsideAngular(() => {
      const editor = grapesjs.init({ container: host, height: '100%' });

      // Re-enter only where editor state has to become Angular state.
      editor.on('component:selected', (component) => {
        this.zone.run(() => this.selectedTag.set(component.get('tagName') ?? ''));
      });

      editor.on('storage:end:store', () => {
        this.zone.run(() => this.savedAt.set(new Date()));
      });

      this.editor = editor;
    });
  }
}

// Zoneless applications (provideZonelessChangeDetection) have no zone to
// leave. Set signals from the same editor events and drop NgZone entirely.

• Erstelle den Editor innerhalb von NgZone.runOutsideAngular(), damit die Canvas-Aktivität keine Änderungserkennung auslöst.
• Geben Sie mit NgZone.run() nur in den Handlern erneut ein, bei denen der Editor-Zustand Angular werden muss – eine Auswahl, ein Speicherzeitstempel, ein Validierungsfehler.
• Wenn in deinem UI nichts den Editor-Status widerspiegelt, musst du nie wieder eingeben.
• In einer zonenlosen Anwendung (provideZonelessChangeDetection) gibt es keine Zone, die man verlassen kann: Schreibe auf Signale aus demselben Editor und verliere NgZone komplett.

Der Editor läuft im Browser. GrapesJS baut seine Canvas aus echtem DOM – es misst Elemente, erstellt ein iframe und hängt Dokumentlistener an – daher muss die Initialisierung im Browserkontext erfolgen und darf nicht während eines Serverrenderings ausgeführt werden. Routen, die lediglich veröffentlichte Ausgaben anzeigen, bleiben unbeeinträchtigt: das ist einfaches HTML und CSS und rendert auf dem Server wie alles andere.

// editor.component.ts — browser-only initialisation
import {
  AfterViewInit,
  Component,
  ElementRef,
  OnDestroy,
  PLATFORM_ID,
  ViewChild,
  inject,
} from '@angular/core';
import { isPlatformBrowser } from '@angular/common';
import type { Editor } from 'grapesjs';

export class EditorComponent implements AfterViewInit, OnDestroy {
  @ViewChild('editorHost') private host!: ElementRef<HTMLDivElement>;

  private readonly isBrowser = isPlatformBrowser(inject(PLATFORM_ID));
  private editor?: Editor;

  async ngAfterViewInit(): Promise<void> {
    if (!this.isBrowser) return;

    // A dynamic import keeps the editor out of the server bundle and off the
    // critical path of every route that never opens it.
    const { default: grapesjs } = await import('grapesjs');
    this.editor = grapesjs.init({ container: this.host.nativeElement });
  }

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

• Guard-Initialisierung, sodass es nur im Browser läuft – sowohl der Plattform-Check als auch der darunterliegende Render-Hook machen das.
• Importiere die Bibliothek dynamisch, damit sie nie ins Server-Bundle gerät.
• Rendere während des Serverdurchlaufs einen Platzhalter derselben Größe, um eine Layout-Verschiebung beim Erscheinen des Editors zu vermeiden.
• Routen zu veröffentlichen, die nur gespeicherte HTML und CSS rendern, benötigen überhaupt keinen Schutz.

Die Render-Hook-Alternative

Neuere Angular-Versionen bieten einen Render-Hook, dessen Rückrufe nur auf Browserplattformen und niemals auf dem Server laufen. Wo er verfügbar ist, gibt er dieselbe Garantie ohne Plattformprüfung und passt natürlich zu signalbasierten View-Abfragen.

// The same guard, expressed with the render hook instead of a platform check.
import { Component, ElementRef, afterNextRender, viewChild } from '@angular/core';
import type { Editor } from 'grapesjs';

@Component({ selector: 'app-editor', template: '<div #editorHost></div>' })
export class EditorComponent {
  private readonly host = viewChild.required<ElementRef<HTMLDivElement>>('editorHost');
  private editor?: Editor;

  constructor() {
    // afterNextRender callbacks run on browser platforms only — they never
    // execute on the server, so no isPlatformBrowser check is needed.
    afterNextRender(async () => {
      const { default: grapesjs } = await import('grapesjs');
      this.editor = grapesjs.init({ container: this.host().nativeElement });
    });
  }
}

Überprüfe, welche dieser Varianten deine Angular-Version unterstützt, bevor du dich entscheidest. Beide Muster existieren, um dieselbe Regel durchzusetzen – der Editor initialisiert im Browser und sonst nirgendwo. angular.dev

Ein Page Builder ist nicht ein einziges Feature. Es sind neun Subsysteme, die miteinander übereinstimmen müssen, und GrapesJS liefert alle neun aus. Das ist der Überblick; die Produktentscheidungen – Preisgestaltung, Rollen, Vorlagen, Veröffentlichungsworkflow – gehören zum unten verlinkten speziellen Leitfaden.

• GrapesJS

  Canvas

  Die editierbare Oberfläche, die in eigenem iframe gerendert wird, sodass Seitenstile nicht in dein Admin-UI gelangen können.

• GrapesJS

  Komponenten

  Das typisierte Modell hinter jedem Element: was es ist, was es akzeptiert und welche Einstellungen es offenlegt.

• GrapesJS

  Block Manager

  Die Palettenbenutzer ziehen von . Ein Block ist ein benannter Inhalt, der einem Komponententyp zugeordnet wird.

• GrapesJS

  Style Manager

  Das CSS-Bearbeitungspanel, konfigurierbar bis hin dazu, welche Eigenschaften ein bestimmter Benutzer ändern darf.

• Plugin

  Asset Manager

  Bild- und Medienauswahl. Der dahinterliegende Upload-Endpunkt gehört dir, daher verbinden Plugins hier meist mit einem Anbieter.

• Deine Angular-App

  Speichermanager

  Laden und speichern. GrapesJS definiert den Vertrag und ruft dein API auf – die Persistenz selbst gehört deiner Anwendung.

• GrapesJS

  Befehle

  Benannte, aufrufbare Aktionen – rückgängig, vorschauen, exportieren und alles, was du für die Symbolleiste registrierst.

• GrapesJS

  Gerätemanager

  Die responsiven Breakpoints, an denen die Canvas vorschauen und gestaltet werden können.

• GrapesJS

  Panels

  Der eigene Chrome des Editors – Buttons, Toolbars und Regionen, alle austauschbar, wenn der Editor in einer bestehenden Shell sitzt.

Acht der neun werden mit dem Editor oder einem Plugin ausgeliefert. Das, was unvermeidlich dir gehört, ist der Speicher – der auch über deine Nutzer, deine Berechtigungen und deine Datenbank Bescheid wissen muss.

Drei Artefakte, und deren Vermischung führt zu echtem Datenverlust. Projektdaten sind das editierbare Dokument; HTML und CSS sind das veröffentlichte Ergebnis. Sie sind nicht austauschbar, da der Export von Natur aus verlustbehaftet ist.

// Three outputs, three different jobs. Do not use one where you need another.

const projectData = editor.getProjectData(); // editable state → store this
const html = editor.getHtml();               // markup         → publish this
const css = editor.getCss();                 // styles         → publish this

// Reopening a saved project restores components, styles, pages and assets.
// Re-parsing exported HTML does not — it loses everything not in the markup.
editor.loadProjectData(projectData);

Das Reparsen von exportiertem HTML in den Editor ist kein Ersatz für Projektdaten: Es verliert Komponententypen, traits, Seitenstruktur und alles andere, was im Markup nicht ausdrückbar war. GrapesJS ist ein Editor, kein CMS oder ein Backend – wohin die Artefakte gelangen und was danach mit ihnen passiert, ist die Entscheidung Ihrer Anwendung.

Der Asset Manager ist ein Picker, kein Dateidienst. Richten Sie ihn auf einen Endpunkt in Ihrer Angular-Anwendung und er wird die Dateien dort POSTEN; alles danach – Validierung, Speicherung, Größenänderung, Auslieferung – steht dir zur Verfügung, was es ermöglicht, die bereits vorhandene Medienbibliothek wiederzuverwenden.

// Assets go to your endpoint, under your auth — GrapesJS only POSTs files.
grapesjs.init({
  container: host,
  assetManager: {
    upload: `/api/projects/${projectId}/assets`,
    uploadName: 'files',
    multiUpload: true,
    credentials: 'include',
    headers: { 'X-Requested-With': 'XMLHttpRequest' },
    // Off by default is the safer choice: base64 images end up inside saved
    // markup and make every page row grow without limit.
    embedAsBase64: false,
    // Returning false aborts the upload before the request leaves the browser.
    beforeUpload: (files: File[]) =>
      files.every((file) => file.size <= MAX_UPLOAD_BYTES && ALLOWED_TYPES.has(file.type)),
  },
});

editor.on('asset:upload:start', () => this.uploading.set(true));
editor.on('asset:upload:end', () => this.uploading.set(false));
editor.on('asset:upload:error', (error) => this.uploadError.set(String(error)));

• Uploads werden mit deinen Headern und Zugangsdaten auf deinen Endpunkt geschickt, sodass die gleiche Authentifizierung wie der Rest der App gilt.
• Überprüfen Sie, bevor die Anfrage den Browser verlässt und erneut auf dem Server ist – die clientseitige Kontrolle ist Bequemlichkeit, keine Kontrolle.
• Gib die gespeicherten URLs von deinem Endpunkt zurück; der Editor fügt diese URLs in die Seite ein, also müssen sie die sein, die du bereitstellen willst.
• Schalte das Base64-Einbetten aus, es sei denn, du möchtest Bilder in gespeicherte Markup-Dateien einfügen, wo jede gespeicherte Seite unbegrenzt wächst.
• Bereite Assets aus einem CDN- oder Objektspeicher bereit und halte den Editor auf die öffentliche URL ausgerichtet, nicht auf den Ursprung deiner Anwendung.
• Laden Sie große Bibliotheken über einen paginierten Endpunkt, anstatt dem Editor bei der Initialisierung Tausende von Assets zu geben.

Nichts davon schreibt ein bestimmtes Backend vor. S3, Cloudinary, eine Laravel-Festplatte oder ein Ordner auf einem Server erfüllen alle denselben Vertrag: eine Datei akzeptieren, eine URL zurückgeben.

Das Registrieren eines Komponententyps ist der Weg, wie der Editor mehr über dein Produkt erfährt. Ein benutzerdefinierter Typ erhält ein eigenes Einstellungspanel, eigene Drag-and-Drop-Regeln und einen Block in der Palette – so arbeiten Content-Teams mit Konzepten aus deiner Domain statt mit rohen Divs.

// pricing-table.type.ts — an application-specific building block.
import type { Editor } from 'grapesjs';

export function registerPricingTable(editor: Editor): void {
  editor.Components.addType('pricing-table', {
    // Lets the editor recognise the type again when a saved page is reparsed.
    isComponent: (el) => el.classList?.contains('pricing-table'),
    model: {
      defaults: {
        tagName: 'section',
        attributes: { class: 'pricing-table' },
        droppable: false,
        // Traits become the right-hand settings panel for this component.
        traits: [
          { type: 'text', name: 'plan', label: 'Plan name' },
          { type: 'number', name: 'price', label: 'Price' },
          { type: 'checkbox', name: 'featured', label: 'Highlight' },
        ],
        components: `
          <h3 data-gjs-type="text">Team</h3>
          <p data-gjs-type="text">$29 / month</p>
        `,
      },
    },
  });

  // A block is how the component reaches the user: one entry in the palette.
  editor.Blocks.add('pricing-table', {
    label: 'Pricing table',
    category: 'Commerce',
    content: { type: 'pricing-table' },
  });
}

Typische anwendungsspezifische Komponenten

• Hero-Abschnitt
• Preistabelle
• Produktkarte
• Formular
• Navigation
• Testimonial
• Funktionsraster
• Alles, was speziell auf dein SaaS zutrifft

Zwei Dinge machen einen benutzerdefinierten Typ nützlich. isComponent ermöglicht es dem Editor, deinen Typ erneut zu erkennen, wenn eine gespeicherte Seite neu geparst wird, und traits wird zum Einstellungspanel, das ein nicht-technischer Nutzer tatsächlich bearbeitet. Beides lohnt sich, selbst für eine einfache Komponente geschrieben zu werden.

Ein Plugin ist eine Funktion, die die Editor-Instanz empfängt, daher ist hier nichts Angular-spezifisch – alles, was für GrapesJS veröffentlicht wird, funktioniert innerhalb einer Angular-Komponente. Das sind die vier Lücken, die Teams zuerst finden, nachdem der Editor gemountet ist.

Blöcke und Voreinstellungen

Was die Nutzer ziehen. Ein blanker Editor hat fast nichts in der Palette, daher ist das das Erste, was jede Integration hinzufügt.

Durchstöbern Sie die Kategorie

Plugin Basic Blocks

Die Startpalette – die Blöcke, die einem neuen Editor beim ersten Durchlauf fehlen.

KostenlosView-Plugin

Grapesjs Tailwind

Tailwind-Kurse im Editor, falls deine Angular-App bereits Tailwind ausliefert.

KostenlosView-Plugin

GrapesJS Bootstrap v5 Blocks

Bootstrap 5-Komponenten als ziehbare Blöcke.

KostenlosView-Plugin

Super Header for GrapesJS

Konfigurierbare Header-Abschnitte statt handgefertigter Markup.

39,00 $View-Plugin

Storage und Projekte

Persistenz, autosave und Multi-Projektmanagement – die Ebene um den Speichervertrag aus dem obigen Abschnitt.

Durchstöbern Sie die Kategorie

Grapesjs Project Manager

Mehrere Projekte in einem Editor, mit einer Projektliste UI.

KostenlosView-Plugin

IndexedDB Storage

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

KostenlosView-Plugin

Autosave & Restore — Crash Recovery for GrapesJS

Stellt nicht gespeicherte Arbeit nach einem Absturz oder einer versehentlichen Navigation wieder her.

12,00 $View-Plugin

Directus Storage

Speicher, der von einer Directus-Instanz unterstützt wird, statt eines maßgeschneiderten Endpunkts.

KostenlosView-Plugin

Reicher Text und Formen

Bessere Inline-Textbearbeitung und reale Formularkomponenten. Beides sind Funktionen, von denen Nutzer annehmen, dass sie eingebaut sind.

Durchstöbern Sie die Kategorie

GrapesJS Inline Text Editor — Compatible with CKEditor 5

Ersetzt den eingebauten Rich-Text-Editor durch CKEditor 5.

69,00 $View-Plugin

TinyMCE 8 Inline Text Editor

Ersetzt den eingebauten Rich-Text-Editor durch TinyMCE 6.

69,00 $View-Plugin

Grapesjs RTE Extensions

Zusätzliche Formatierungssteuerungen auf der Standard-Rich-Text-Symbolleiste.

KostenlosView-Plugin

Plugin Forms

Formularkomponenten mit echten Eingaben, Validierungs-traits und Einreichungseinstellungen.

KostenlosView-Plugin

Assets, Export und E-Mail

Medienanbieter, Exportformate und das E-Mail-Preset für die Oberflächen, in die ein Builder wächst.

Durchstöbern Sie die Kategorie

Grapesjs Cloudinary

Cloudinary als Asset-Backend, einschließlich Transformationen.

KostenlosView-Plugin

Export Zip

Exportiert die Seite als herunterladbare ZIP von HTML, CSS und Assets.

KostenlosView-Plugin

MJML Preset

MJML blockiert, sodass derselbe Editor e-mail-sichere Markup-Arbeiten erzeugen kann.

KostenlosView-Plugin

Grapesjs A11Y Seo — Accessibility auditor + SEO for GrapesJS

Barrierefreiheit und SEO überprüfen im Editor, bevor eine Seite veröffentlicht wird.

KostenlosView-Plugin

Einen visuellen Editor zu erstellen ist in Angular möglich – es ist eine bekannte Menge an Arbeit, keine unmögliche. Die Frage ist, welche Teile davon du für die Lebensdauer des Produkts besitzen möchtest.

"Bauen" ist keine Kritik – jede einzelne davon ist baubar. Es ist eine Aussage darüber, wer sie danach pflegt.
Die Fakten in dieser Tabelle bestätigen 2026-09-02 erneut.

Nein, und es lohnt sich zu verstehen, warum die Frage aufkommt. GrapesJS veröffentlicht einen offiziellen React-Wrapper, daher erwarten Entwickler vernünftigerweise ein Angular-Äquivalent. Es gibt keinen. Das lässt drei Ansätze übrig, und für die meisten Teams ist die erste die richtige Antwort.

Eine Demo ist eine Komponente. Ein Produkt besteht aus vier Ebenen, und der Editor ist nur eine davon. Das ist die Form, auf die sich die meisten Teams konzentrieren, sobald der Editor echte Nutzer hinter sich hat.

1. 01

   Angular-Anwendung

   Die Shell, der Router und eine faul geladene Route, die den Editor besitzt.

   • App Shell
   • Router
   • Editor-Route (Lazy Loading)
   ↓
2. 02

   GrapesJS-Instanz

   Einmal konfiguriert, bei der Initialisierung: Welche Komponenten existieren, was kann gezogen werden, was kann gestaltet werden.

   • Komponenten
   • Blöcke
   • Stile
   • Assets
   • Befehle
   ↓
3. 03

   Anwendungsdienste

   Die Angular-Schicht zwischen dem Editor und deinem API – und der einzige Ort, an dem die Autorisierungsentscheidungen clientseitig getroffen werden.

   • Auth
   • API-Client
   • Berechtigungen
   • Veröffentlichung
   ↓
4. 04

   Backend

   Wo die Artefakte wohnen und wo jede Erlaubnis wirklich durchgesetzt wird.

   • Projekte
   • Assets
   • Nutzer
   • Versionen

Nichts in diesem Diagramm ist GrapesJS-spezifisch, außer der zweiten Stufe. Das ist der Punkt: Der Editor ist eine Komponente in einer gewöhnlichen Angular-Anwendung, und der Rest ist die Architektur, die du sowieso gebaut hättest.

Der Editor ist ein großes Stück Software, das in deiner Anwendung läuft. Das sind die Bereiche, in denen das tatsächlich etwas kostet.

Zwölf Dinge, die eine funktionierende Demo von einer Route unterscheiden, die echte Nutzer unterscheidet, können bereitgestellt werden.

1. ✓

   GrapesJS installieren

   Abhängigkeit hinzugefügt und das Stylesheet wird entweder global oder in der Editor-Komponente registriert.

   Lies den Abschnitt
2. ✓

   Initialisieren nach Ansichtserstellung

   grapesjs.init() läuft in ngAfterViewInit gegen einen Container mit einer aufgelösten Höhe.

   Lies den Abschnitt
3. ✓

   Zerstöre den Editor korrekt

   editor.destroy() in ngOnDestroy, verifiziert, indem man ohne Lecks weg und zurück navigiert.

   Lies den Abschnitt
4. ✓

   Browser-only-Initialisierung verwalten

   Bewacht, sodass während eines Server-Renderings nichts läuft, mit einem Platzhalter an seiner Stelle.

   Lies den Abschnitt
5. ✓

   Verbindungsspeicher

   Ein benannter Speicher ist registriert, autosave optimiert und das Projekt JSON wird zusammen mit HTML und CSS gespeichert.

   Lies den Abschnitt
6. ✓

   Assets konfigurieren

   Uploads zeigen auf dein Endpunkt, base64 wird aktiviert, Validierung auf beiden Seiten.

   Lies den Abschnitt
7. ✓

   Fügen Sie benutzerdefinierte Komponenten hinzu

   Die eigenen Bausteine Ihres Produkts sind als Typen registriert, mit traits und Paletteneinträgen.

   Lies den Abschnitt
8. ✓

   Füge die Plugins hinzu, die du brauchst

   Blöcke, Rich Text und Export wurden bewusst gewählt statt angesammelt.

   Lies den Abschnitt
9. ✓

   Implementierung von Berechtigungen

   Wer bearbeiten darf, wer veröffentlichen darf – das wird auf dem Server durchgesetzt, was sich im UI widerspiegelt.

   Lies den Abschnitt
10. ✓

    Veröffentlichte Inhalte desinfizieren

    Serverseitige Sanierung zwischen dem Speichern einer Seite und deren Bereitstellung an Besucher.

    Lies den Abschnitt
11. ✓

    Fehler im Monitor-Editor

    Editor-Ausnahmen wurden an derselben Stelle gemeldet wie der Rest deiner Angular-Fehler.

12. ✓

    Test-responsives Schneiden

    Der Gerätemanager wurde auf einem Touch-Gerät trainiert, nicht nur im Desktop-Browserfenster.

    Lies den Abschnitt

Beginnen Sie mit dem Open-Source-Visual-Editor, verbinden Sie ihn mit Ihrer Angular-Anwendung und erweitern Sie ihn mit den Plugins und Integrationen, die Ihr Produkt benötigt.