Text Editor - Tree Shaking

How import style decides which parts land in the bundle, and what can actually be dropped.

#Overview

Every part is available two ways from the same package: flat named imports that tree-shake, and a compound TextEditor namespace that reads cleanly but pins every part into the bundle. One thing to keep in mind: a rich text editor has a floor that no import style removes. ProseMirror, the schema, and the Root and Content machinery come along regardless. What flat imports drop is the UI parts that are never composed: table menus, the mention and slash menus, image and document upload, the block navigator.

#Flat Imports

Import each part by its prefixed name:

import { TextEditorRoot, TextEditorToolbar, TextEditorContent } from '@primeui/vue-texteditor';
<template>
    <TextEditorRoot>
        <TextEditorToolbar />
        <TextEditorContent />
    </TextEditorRoot>
</template>

Only the named parts survive the build. Every part has a flat name: TextEditorRoot, TextEditorToolbar, TextEditorMentionMenu, TextEditorTableColumnMenu, and so on.

#Compound API

import { TextEditor } from '@primeui/vue-texteditor';
<template>
    <TextEditor.Root>
        <TextEditor.Toolbar />
        <TextEditor.Content />
    </TextEditor.Root>
</template>

This exposes <TextEditor.Root>, <TextEditor.Toolbar>, and the rest off one object. It reads well and there is nothing to look up. The trade is that the parts are read as members at runtime, so a bundler keeps all of them whether or not the template uses them. A toolbar and content editor still ships the table menus and the mention menu. On a lazy-loaded page that rarely matters.

#Part Subpaths

For the leanest build, pull a single part from its own entry:

import { TextEditorRoot } from '@primeui/vue-texteditor/parts/root';
import { TextEditorContent } from '@primeui/vue-texteditor/parts/content';

There is one subpath per part: root, toolbar, content, navigator, blockcontrols, blockmenu, blocksubmenu, contexttoolbar, contexttoolbarmore, slashmenu, mentionmenu, tablecontrols, tablecolumnmenu, tablecolumnsubmenu, tablerowmenu, tablerowsubmenu, tablecellmenu, tablecellsubmenu, imageupload, documentupload. This lands at the same size as the flat import for the same set of parts, so it fits when each part should sit in its own module rather than for an extra size win.

#Bundle Impact

For an editor that only mounts Root and Content, the compound import still carries the mention menu, slash menu, all the table menus, and the upload parts even though the template never renders them. The flat import drops the lot, and the per-part subpaths land at the same place. Keep in mind the ProseMirror runtime and the shared editor core are paid either way, so the real first-load difference on a page that already loads Vue is smaller than the part list suggests. The win is proportional to how many UI parts go unused.

#Choosing an Import Style

The flat imports are the size-safe default and read almost as cleanly as the namespace. The compound API is fine when readability wins and the page is lazy-loaded. Per-part subpaths fit when each part belongs in its own module. The biggest single win is almost always lazy-loading the editor page, regardless of import style.