Angular Page Builder with GrapesJS

The stock editor: canvas, blocks, layer tree, style manager and device switcher. This is the foundation you start from before adding a single block of your own.

Building a page builder takes much more than a few Angular components. A production-ready visual editor needs every one of these before anyone can ship a page with it:

• Drag & drop
• Canvas
• Components
• Blocks
• Layers
• Styles
• Responsive editing
• Asset management
• Templates
• Project storage
• Export
• Publishing

GrapesJS provides the visual editing foundation for most of that list, so your Angular application can spend its budget on your product and your business logic instead. The last two — where projects are stored and how pages go live — stay yours, because they are the parts that have to match your infrastructure.

GrapesJS core is open source under the BSD-3-Clause licence, version 0.23.6, with no licence fee at any scale.

The editor is one route inside your application, not a replacement for it. Everything above the editing layer stays exactly where Angular teams already put it.

1. 01

   Angular application

   Everything that makes your product yours, unchanged.

   • Authentication
   • Users
   • Billing
   • Routing
   • Business logic
   ↓
2. 02

   Visual page builder

   A lazy-loaded route, a component that owns the container, and a service that owns the editor instance.

   • Editor route
   • Editor component
   • Editor service
   ↓
3. 03

   GrapesJS

   The visual editing engine, running inside the container your component provides.

   • Canvas
   • Components
   • Blocks
   • Layers
   • Styles
   • Assets
   • Commands
   ↓
4. 04

   Your backend

   Where project data, uploads and published output actually live.

   • Your API
   • Your database
   • File storage

Angular owns your application. GrapesJS powers the visual editing layer.

Nothing in the top or bottom tier is provided by the editor. That boundary is what keeps the integration shallow enough to remove later — the editor never becomes the thing your product is built around.

A generic website builder is rarely the product anyone wants. Every layer of the editor can be replaced with something that matches your application instead.

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

The difference between an editor people use and one they abandon is usually what is in the palette on day one.

GrapesJS serialises a project to JSON and hands it to a storage adapter. What that adapter does is entirely yours.

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 },
});

• Project data

  Components, styles, pages and assets serialise to a JSON document you can store in any column or collection.

• Autosave

  The storage manager can save after a configurable number of changes rather than only on an explicit action.

• Remote storage

  Register a custom adapter and route load and store through Angular's HttpClient, with your own interceptors and auth headers.

• Versioning

  Because each save is a document, keeping history is a backend decision — the editor does not need to know it happened.

• HTML/CSS output

  Export the rendered markup alongside the project JSON when your delivery path needs static output rather than a re-render.

• Publishing

  A published page is a separate record with its own lifecycle. Keep it apart from the draft the editor writes to.

You control where project data is stored.

Authoring and publishing are different problems with different failure modes. The editor solves the first one; the second stays in your infrastructure, where your caching, permissions and rollbacks already live.

Where published output can go

• CMS

  Write the output back into the content system your organisation already runs.

• REST API

  Post the project or the rendered markup to an endpoint that owns validation and permissions.

• Static publishing

  Render pages to files at publish time so the live page carries none of the editor's runtime.

• Custom backend

  Store, transform and serve the output through the same path your application already uses to serve its pages.

• CDN

  Push published assets and markup to the edge, with cache invalidation you control.

• Custom deployment

  Trigger your existing build or deploy pipeline from the publish action.

GrapesJS handles authoring. Your infrastructure can handle publishing.

One deployment of your Angular application, one editor, and a separate world of pages for every customer in it.

Nothing about the editor has to look like the editor. Every surface a user touches is configurable, replaceable or removable.

• Your logo in place of the editor's chrome
• Your colour tokens, not a third-party theme
• Custom panels, or your own Angular UI driving the editor through commands
• Only the blocks your product supports
• Templates that come from your design system
• Your vocabulary — sections, modules, layouts, whatever your users already say
• Roles that decide who may edit, who may publish and who may only comment
• Permissions enforced on the server, reflected in the UI

Turn a visual editor into a native part of your Angular product.

The short version, in four steps. The complete guide — lifecycle details, wrappers, zoneless change detection, production concerns — lives on its own page and goes much further than this.

1. 1

   Install

   Add the editor to your application. It is a plain npm package with no Angular-specific build step.

2. 2

   Create an editor service

   Keep the editor instance in an injectable service so the component stays thin and the instance is easy to share, mock and tear down.

3. 3

   Initialize in ngAfterViewInit

   The container element must be in the DOM before the editor is created, because GrapesJS measures it immediately.

4. 4

   Destroy correctly in ngOnDestroy

   Call destroy when the route is left. Without it the editor keeps its DOM listeners and the next navigation leaks an 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 emits its own events, and those events do not come from Angular. Coordinating the two is a few lines, but skipping it produces the two bugs every integration hits first.

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()));
});

Create the editor inside runOutsideAngular so canvas interaction does not schedule change detection on every frame, then re-enter the zone in the handful of event handlers that actually update state your template renders. On a zoneless application the same handlers update signals instead, and the outer wrapper is no longer needed.

GrapesJS needs a browser DOM. Under Angular SSR or Angular Universal that means the editor is created in the browser only — the route around it still renders on the server as normal.

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

The integration is ordinary Angular code, which is the main thing worth saying about it.

• TypeScript-friendly

  The editor ships its own type definitions, so the instance, its configuration and its events are typed at the call site.

• Angular lifecycle

  Creation and teardown hang off ngAfterViewInit and ngOnDestroy — no manual bootstrapping outside the component tree.

• AOT-compatible

  Nothing in the integration depends on runtime template compilation, so the editor route builds like any other lazy-loaded route.

• Browser-only initialization

  Where SSR is in play, only the editor creation is browser-guarded; the rest of the component compiles and renders normally.

The engine gives you the editing surface. Everything a specific product needs on top of it — the block palette, the template system, rich text, persistence, the exit path to production — is where GJS.Market plugins come in. Every listing below is a real product, priced as shown.

Blocks

Problem: a fresh editor has an empty palette, and nobody builds a page out of a bare <div>.

Browse this category

Blocks

Plugin Basic Blocks

The starting palette: columns, text, images, links and video, so the canvas is usable on day one.

FreeView plugin

Blocks

Grapesjs Tailwind

Tailwind-based blocks, so pages users build come out matching a utility design system you already use.

FreeView plugin

Blocks

GrapesJS Bootstrap v5 Blocks

Bootstrap 5 grid and component blocks for teams whose design system is already Bootstrap.

FreeView plugin

Blocks

Super Header for GrapesJS

One header edited once and reused across every page, instead of copies drifting apart.

$39.00View plugin

Templates & pages

Problem: users need somewhere to start, and multi-page projects need a manager the editor does not ship.

Browse this category

Templates

Templates Manager

A template library inside the editor, so a new page starts from a finished layout.

$39.00View plugin

Pages

Pages Manager

Multi-page projects with a page list, so a builder handles a site rather than a single document.

$25.00View plugin

Blocks

Users Blocks

Lets users save their own sections as reusable blocks — your palette grows without you shipping anything.

$59.00View plugin

Projects

Grapesjs Project Manager

Project browsing and management around the editor, for teams working on more than one thing at a time.

FreeView plugin

Text & forms

Problem: everyone assumes rich text and working forms are built in. Neither is, beyond the basics.

Browse this category

Forms

Plugin Forms

Form components with inputs, selects and validation traits, ready to submit to your endpoints.

FreeView plugin

RTE

GrapesJS Inline Text Editor — Compatible with CKEditor 5

Replaces the built-in rich text editor with CKEditor 5 for teams that need serious text editing.

$69.00View plugin

RTE

TinyMCE 8 Inline Text Editor

The same, with TinyMCE 6 — familiar to anyone coming from a traditional CMS.

$69.00View plugin

RTE

Grapesjs RTE Extensions

Extra formatting controls on the default rich text editor without adding a third-party dependency.

FreeView plugin

Storage & output

Problem: the prototype that never persisted anything is the one that never shipped.

Browse this category

Storage

IndexedDB Storage

Local persistence in the browser: useful for drafts, offline editing and preview environments.

FreeView plugin

Storage

Directus Storage

Stores projects in Directus, if a headless backend is already part of your stack.

FreeView plugin

Export

Export Zip

Downloads a page as a ZIP of HTML, CSS and assets — the simplest possible export path.

FreeView plugin

Publishing

Grapesjs Netlify

Publishes straight to Netlify, for products whose output is a hosted static site.

FreeView plugin

Both columns end with a working builder. They differ in how much of it you are still maintaining in two years.

GrapesJS provides the visual editing foundation. GJS.Market plugins let you extend your builder with additional capabilities instead of building every feature internally.

Use Angular for your application and GrapesJS for the visual editing experience. Add your own components, blocks, templates, storage and publishing workflow — then extend the builder with GJS.Market plugins when you need more.