GrapesJS Vue: Build a Visual Editor with Vue 3

Yes. GrapesJS is framework-agnostic and can be integrated directly into Vue 3 applications. You can initialize the editor with Vue lifecycle hooks, keep the editor instance in a composable or component, connect GrapesJS events to your Vue application, and persist project data through your own backend.

Two ways to do it

GrapesJS publishes one official framework wrapper, @grapesjs/react, for React. There is no equivalent Vue package from the GrapesJS project, so any Vue wrapper you find on npm is a community project. Check its Vue and GrapesJS peer ranges before you adopt it.

Vue 3 is an application framework. GrapesJS is a visual editing engine. They solve different problems, and the integration is clean precisely because they do not overlap.

Five of these are yours. The rest already exist, and the two remaining are configuration rather than construction.

One dependency. GrapesJS ships its own TypeScript definitions, so there is no separate @types package to add.

Copy this into a component and it runs. Everything after this section is an addition to it, not a rewrite of it.

<template>
  <div ref="editorContainer" class="editor-shell"></div>
</template>

<script setup lang="ts">
import { onMounted, onUnmounted, shallowRef, ref } from 'vue';
import grapesjs, { type Editor } from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';

// A template ref: the name matches the ref="" attribute above.
const editorContainer = ref<HTMLDivElement | null>(null);

// shallowRef, not ref — see "Performance" further down the page.
const editor = shallowRef<Editor | null>(null);

onMounted(() => {
  if (!editorContainer.value) return;

  editor.value = grapesjs.init({
    container: editorContainer.value,
    height: '100%',
    fromElement: false,
    storageManager: false,
  });
});

onUnmounted(() => {
  editor.value?.destroy();
  editor.value = null;
});
</script>

<style scoped>
.editor-shell {
  height: 100vh;
}
</style>

The whole integration is a lifecycle mapping. Vue tells you when the DOM node exists and when it is about to disappear; GrapesJS needs exactly those two moments.

Read top to bottom, that is the entire contract between the two libraries.

Neither onMounted nor onUnmounted runs on the server, which is why a plain Vue SPA needs nothing extra. A server-rendered app needs one more guard — the Nuxt section covers it.

Once a second screen needs an editor, move the lifecycle into a composable. The component then says what it wants, not how the editor is wired.

// composables/useGrapesJS.ts
import { onMounted, onUnmounted, shallowRef, type Ref } from 'vue';
import grapesjs, { type Editor, type EditorConfig } from 'grapesjs';
import 'grapesjs/dist/css/grapes.min.css';

type EditorOptions = Omit<EditorConfig, 'container'>;

export function useGrapesJS(
  container: Ref<HTMLElement | null>,
  options: EditorOptions = {},
) {
  const editor = shallowRef<Editor | null>(null);

  const init = (): Editor | undefined => {
    if (editor.value || !container.value) return;

    editor.value = grapesjs.init({
      container: container.value,
      height: '100%',
      fromElement: false,
      storageManager: false,
      ...options,
    });

    return editor.value;
  };

  const destroy = (): void => {
    editor.value?.destroy();
    editor.value = null;
  };

  onMounted(init);
  onUnmounted(destroy);

  return { editor, init, destroy };
}

<template>
  <div ref="editorContainer" class="editor-shell"></div>
</template>

<script setup lang="ts">
import { ref } from 'vue';
import { useGrapesJS } from '~/composables/useGrapesJS';

const editorContainer = ref<HTMLElement | null>(null);

const { editor } = useGrapesJS(editorContainer, {
  blockManager: {
    blocks: [
      {
        id: 'hero',
        label: 'Hero',
        category: 'Sections',
        content: '<section>…</section>',
      },
    ],
  },
});
</script>

Resist growing this further than it needs to be. A composable that wraps every GrapesJS module in a reactive facade is a second API to learn and a second thing to keep in sync.

GrapesJS manages editor state. Vue manages application state. Events are the seam: subscribe to the few that your UI actually reflects, and write them into ordinary refs.

import { onMounted, ref, shallowRef } from 'vue';
import type { Editor, Component } from 'grapesjs';

const isReady = ref(false);
const isDirty = ref(false);
const saveState = ref<'idle' | 'saving' | 'saved' | 'error'>('idle');
const selectedName = ref<string | null>(null);

function bindEditorEvents(editor: Editor): void {
  editor.on('load', () => {
    isReady.value = true;
  });

  editor.on('component:selected', (component: Component) => {
    selectedName.value = component?.getName?.() ?? null;
  });

  editor.on('component:update', () => {
    isDirty.value = true;
  });

  editor.on('storage:start:store', () => {
    saveState.value = 'saving';
  });

  editor.on('storage:end:store', () => {
    saveState.value = 'saved';
    isDirty.value = false;
  });

  editor.on('storage:error', () => {
    saveState.value = 'error';
  });
}

Mirror what you display, not what the editor holds. Copying the component tree into a Vue store gives you two sources of truth and a synchronisation bug.

GrapesJS relies on browser DOM APIs, so editor initialization should happen only in a browser context. In Nuxt that means keeping the editor out of the server render — everything else is the same integration you already have.

<!-- pages/editor.vue -->
<template>
  <ClientOnly>
    <VisualEditor />

    <template #fallback>
      <p class="editor-placeholder">Loading the editor…</p>
    </template>
  </ClientOnly>
</template>

<!-- components/VisualEditor.client.vue -->
<template>
  <div ref="editorContainer" class="editor-shell"></div>
</template>

<script setup lang="ts">
import { ref } from 'vue';
import { useGrapesJS } from '~/composables/useGrapesJS';

// Reached only in the browser: the .client suffix keeps this
// component out of the server render, and onMounted never runs
// on the server anyway.
const editorContainer = ref<HTMLElement | null>(null);
const { editor } = useGrapesJS(editorContainer);
</script>

Two correct options

Both are valid, and they combine. Neither is required by GrapesJS — what GrapesJS requires is simply that init() runs where document exists.

No. Direct integration is a complete, supported way to use GrapesJS, and it is what the examples on this page do. A wrapper is a convenience, not a requirement.

For Vue 3 today, the composable above is the wrapper. It is twenty-odd lines, it uses the GrapesJS API directly, and it cannot fall behind a release you depend on.

Mounting the editor is the first afternoon. A page builder your users trust is the rest of the work, and it is mostly configuration of the modules GrapesJS already exposes.

• Canvas

  The editable surface and its device widths.

• Components

  The types your users can place, and their traits.

• Blocks

  The palette they drag from.

• Style Manager

  Which CSS properties are exposed, and to whom.

• Asset Manager

  Images and media, from your storage.

• Storage Manager

  Where project data is loaded and saved.

• Commands

  Named actions, bindable to your own UI.

• Device Manager

  Responsive breakpoints for editing and output.

• Plugins

  Everything above, packaged and reusable.

The same editor core, configured differently. Each of these is a different set of blocks, a different storage target and a different publish step.

Three things that are easy to conflate, and expensive to conflate. Getting this right on day one is what makes a document re-editable a year later.

1. User edits
2. ↓→
3. GrapesJS project data
4. ↓→
5. Your API / database
6. ↓→
7. HTML + CSS
8. ↓→
9. Preview / publish

Store editable project data. Generate HTML and CSS when you need to render or publish.

// Editable state — store this, it is what the editor reloads.
const projectData = editor.getProjectData();

// Rendered output — regenerate this whenever you publish.
const html = editor.getHtml();
const css = editor.getCss();

await fetch(`/api/projects/${projectId}/publish`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ projectData, html, css }),
});

// Sanitize `html` on the server before it is served to anyone.

GrapesJS does not care what your backend is. A storage adapter is two async functions — one that returns project data, one that accepts it — so the editor talks to the API you already have.

1. Vue
2. ↓→
3. GrapesJS storage
4. ↓→
5. REST API
6. ↓→
7. Backend
8. ↓→
9. Database

import grapesjs, { type ProjectData } from 'grapesjs';

// Wherever your app keeps it — a route param, a prop, a store.
const projectId = props.projectId;

const editor = grapesjs.init({
  container: editorContainer.value!,
  fromElement: false,
  storageManager: {
    type: 'app-api',
    autosave: true,
    stepsBeforeSave: 10,
  },
  // Registered as a plugin so the adapter exists before
  // GrapesJS performs its first load.
  plugins: [
    (ed) => {
      ed.Storage.add('app-api', {
        async load(): Promise<ProjectData> {
          const res = await fetch(`/api/projects/${projectId}`);
          if (!res.ok) {
            throw new Error(`Load failed: ${res.status}`);
          }
          return await res.json();
        },

        async store(data: ProjectData) {
          const res = await fetch(`/api/projects/${projectId}`, {
            method: 'PUT',
            headers: { 'Content-Type': 'application/json' },
            body: JSON.stringify({ projectData: data }),
          });
          if (!res.ok) {
            throw new Error(`Save failed: ${res.status}`);
          }
        },
      });
    },
  ],
});

Registering the adapter through the plugins array matters: it guarantees the storage exists before GrapesJS performs its first load.

The asset manager is a UI over an endpoint. Point it at yours and every existing rule — auth, validation, quotas, CDN — keeps applying.

// Fetched from your own API before the editor is created.
const assets = await fetch('/api/assets').then((res) => res.json());

const editor = grapesjs.init({
  container: editorContainer.value!,
  assetManager: {
    assets,

    // Uploads go to your endpoint, with your auth and
    // your validation.
    upload: '/api/assets',
    uploadName: 'files',
    multiUpload: true,
    autoAdd: true,
    headers: { Authorization: `Bearer ${token.value}` },
    credentials: 'same-origin',

    // Reject what the backend would reject anyway,
    // before the round trip.
    beforeUpload: (files: File[]) => {
      const limit = 5 * 1024 * 1024;
      const tooBig = files.some((f) => f.size > limit);
      if (tooBig) {
        toast.error('Images must be under 5 MB');
        return false;
      }
    },
  },
});

A custom component type is how the editor learns your product. It gets its own settings panel, its own drop rules and its own block in the palette.

import type { Editor } from 'grapesjs';

export function pricingCardPlugin(editor: Editor): void {
  editor.Components.addType('pricing-card', {
    isComponent: (el) => el.dataset?.gjsType === 'pricing-card',
    model: {
      defaults: {
        tagName: 'section',
        attributes: { 'data-gjs-type': 'pricing-card' },
        // Traits become the settings panel for this component.
        traits: [
          { type: 'text', name: 'plan', label: 'Plan name' },
          { type: 'text', name: 'price', label: 'Price' },
          { type: 'checkbox', name: 'featured', label: 'Featured' },
        ],
        components: `
          <h3 data-gjs-type="text">Starter</h3>
          <p data-gjs-type="text">$0 / month</p>
          <a href="#">Choose plan</a>
        `,
      },
    },
  });

  editor.Blocks.add('pricing-card', {
    label: 'Pricing card',
    category: 'Marketing',
    content: { type: 'pricing-card' },
  });
}

// Pass it to the editor like any other plugin:
// grapesjs.init({ container, plugins: [pricingCardPlugin] })

A plugin is a function that receives the editor — the same function signature whether it came from npm, from GJS.Market, or from your own repository. None of them care that the host application is Vue.

import grapesjs from 'grapesjs';
import basicBlocks from 'grapesjs-blocks-basic';
import { pricingCardPlugin } from '~/editor/pricing-card';

const editor = grapesjs.init({
  container: editorContainer.value!,
  plugins: [
    // Options go through a wrapper function: `pluginsOpts`
    // is keyed by string, so it only reaches plugins that
    // were passed to `plugins` by name.
    (ed) => basicBlocks(ed, { flexGrid: true }),
    pricingCardPlugin,
  ],
});

Not an argument that building is wrong — an inventory of what building means. Every row is a subsystem that exists whether or not you planned for it.

Vue gives you the application framework. GrapesJS gives you the visual editing engine.

The editor is a leaf in that tree, not the root. Everything above it is code you would have written anyway.

Almost every integration issue reported for this combination is one of these seven.

On Vue 2 the same integration uses mounted() and beforeDestroy() instead of onMounted() and onUnmounted(); the GrapesJS side is unchanged. New work should target Vue 3 — everything on this page assumes it.

The order roughly matches the order this page introduced them.

1. ✓Install GrapesJS
2. ✓Initialize after mount
3. ✓Destroy on unmount
4. ✓Import the GrapesJS CSS
5. ✓Handle SSR / client-only execution
6. ✓Decide direct integration vs wrapper
7. ✓Create a reusable composable where useful
8. ✓Connect the editor events your UI reflects
9. ✓Configure storage
10. ✓Configure assets
11. ✓Add custom components
12. ✓Add the plugins your product needs
13. ✓Implement permissions server-side
14. ✓Sanitize published content
15. ✓Test responsive editing
16. ✓Test the production build