Craft.js 替代方案：打造生产级可视化编辑器，请用 GrapesJS

没有分数，因为行数值不一致。每个能力都标注了它的来源：包含在项目中、通过插件访问，还是由你自己的代码定义。

• ✓内置
• +附加组件
• ·自定义

与两个项目在2026-09-03上的文档对照：Craft.js 0.2.12和GrapesJS 0.23.6。“自定义”是描述，而非批评——在几行中，这正是团队选择无主见框架的原因。

最大的区别不仅仅是功能数量。这两个框架为开发者提供了不同的视觉编辑器起点。

• 由框架提供
• 由您提供

如果你需要建造的层在第一列中高于Craft.js，那么GrapesJS值得评估。如果层级低于Craft.js，迁移几乎没有什么好处。

下面的信号大致说明你本来需要制作的内容。每张卡片收集其中几个信号;如果有几个信号描述了你的项目，评估就值得你花时间。

原装的GrapesJS编辑器，没有插件，也没有设计系统。这是核心在你配置任何东西之前给你的。

这两个项目都把用户拖动的东西称为“组件”，但这两个定义不能互换。这就是决定迁移工作量的区别。

这些概念的对应

• Craft.js Component→↓GrapesJS Component Type

  带有Craft.js描述符的React组件会成为带有模型和默认值的注册组件类型。它产生的标记会进入该模型。

• React Props→↓Traits / Properties / Attributes

  编辑器用户可以更改的道具变成traits。道具只有你的代码集变成属性或固定模型属性。

• Craft.js Editor State→↓GrapesJS Project Data

  序列化的节点树变成了项目数据。两者都是JSON，但形状不同，所以这是一个你写入并测试的变换。

• Custom Editor UI→↓GrapesJS UI + Custom Commands / Panels

  你在React里写的设置面板被内置的特性面板取代，还有自定义命令和核心没有的行为面板。

这是一种概念映射，不是自动转换。没有工具读取Craft.js解析器并输出GrapesJS组件类型——上述对应关系是你实现的，每个组件类型一次。

同样的理念——一个带有可编辑标题和描述的hero部分——在两侧都定义了。把它们当作一个概念的两个定义，而不是同一文件的对比和之后。

// Craft.js: a component is a React component plus a `craft` descriptor.
// The editor drives it through connectors from useNode().
import { useNode } from '@craftjs/core';

export const Hero = ({ title, description }) => {
  const { connectors: { connect, drag } } = useNode();

  return (
    <section ref={(ref) => connect(drag(ref))} className="hero">
      <h1>{title}</h1>
      <p>{description}</p>
    </section>
  );
};

Hero.craft = {
  props: {
    title: 'Build faster',
    description: 'Create beautiful pages',
  },
  related: {
    // The panel that edits those props is a React component you write.
    settings: HeroSettings,
  },
};

// GrapesJS: a component type owns its markup and its editable traits.
// Traits are the closest analogue to Craft.js props.
editor.Components.addType('hero', {
  model: {
    defaults: {
      tagName: 'section',
      attributes: { class: 'hero' },
      traits: [
        { name: 'title', type: 'text', changeProp: true },
        { name: 'description', type: 'text', changeProp: true },
      ],
      components: [
        { tagName: 'h1', type: 'text', content: 'Build faster' },
        { tagName: 'p', type: 'text', content: 'Create beautiful pages' },
      ],
    },
  },
});

// A block is what makes the type draggable from the panel. Craft.js derives
// the equivalent from your toolbox; in GrapesJS it is a separate registration.
editor.Blocks.add('hero', {
  label: 'Hero',
  category: 'Sections',
  content: { type: 'hero' },
});

// The trait panel edits those traits. You do not write it.

以及已经存在的内容

Component 定义只是其中一半。你用户已经创建的所有内容都存储在 Craft.js 节点格式中，迁移它意味着要走过那棵树，并输出你新组件类型理解的定义。

// Craft.js persists `query.serialize()` — a JSON map of nodes keyed by id,
// each with { type: { resolvedName }, props, nodes }. Migrating it means
// walking that map and emitting the GrapesJS component definitions your new
// types understand: a transform you write once, per component type.
const toGrapesJs = {
  Hero: ({ title, description }) => ({ type: 'hero', title, description }),
  // …one entry per resolver entry in your Craft.js editor
};

function craftNodeToGjs(nodes, id) {
  const node = nodes[id];
  const map = toGrapesJs[node.type.resolvedName];
  if (!map) throw new Error(`Unmapped Craft.js component: ${node.type.resolvedName}`);

  return {
    ...map(node.props),
    components: (node.nodes ?? []).map((child) => craftNodeToGjs(nodes, child)),
  };
}

const nodes = JSON.parse(craftSerializedJson);
editor.setComponents(craftNodeToGjs(nodes, 'ROOT').components);

这两个样本都是说明性的。它们展示了映射的形状和变换的形状;这两个都不是插入迁移，项目中也没有生成任何一个。

大致分为三个层级。这些层面都没有持续时间，因为真正的答案完全取决于你的代码库——而一个承诺给你一个无法得知的数字的页面，并不能帮你规划。

1. 简单

   基础组件，少量自定义编辑器逻辑

   有几种组件类型，一个小的设置表面，以及尚未积累太多变体的内容。

   你可能在这里，如果

   • 少于十种组件类型
   • 设置面板大多是文字和数字输入
   • 目前几乎没有内容投入制作

   通常是相对有针对性的迁移。

2. 中等

   自定义组件、编辑器界面、存储和模板

   一个真正的编辑器，拥有自己的面板、模板库、保存的文档和一个组件集，并且已经扩展到适合产品的组件集。

   你可能在这里，如果

   • 带有条件字段的自定义设置面板
   • 一个用户可以从中开始的模板库
   • 必须存活下来的保存内容

   需要组件和数据映射。

3. 复杂

   深度 React 渲染依赖与自定义行为

   Components 依赖于应用上下文、编辑器行为在不明显的地方扩展，以及嵌入在编辑体验中的业务规则。

   你可能在这里，如果

   • Components 读取应用状态或上下文来渲染
   • 自定义状态管理通过编辑器连接
   • 这些业务规则存在于编辑者的行为中，而非数据中

   需要架构审查和分阶段迁移。

迁移复杂度取决于现有应用与Craft.js的深度耦合程度。

这些方框是可打印的计划，不是保存状态——这里没有存储在浏览器里。把步骤复制到你团队已经用的追踪器里。

团队实际的做法

1. 1

   在GrapesJS中重建视觉定义

   把你的 React 组件产生的标记和样式，用 traits 表示为组件类型。这是默认路径，通常比听起来省事，因为标记已经存在。

   费用： 每个组件类型都有一个定义，手写并像其他代码一样审查。

2. 2

   在编辑器之外重用业务逻辑

   定价规则、验证、数据获取和格式化很少属于编辑者。将它们整合进编辑调用的模块中，迁移后它们依然完好无损。

   费用： 这需要先把逻辑和渲染分开，这通常无论如何都值得做。

3. 3

   构建一个真正需要React渲染的集成层

   有些组件在渲染时确实需要React。这些可以渲染到编辑器拥有的容器中，编辑者将结果视为一个组件。

   费用： 最贵的选择。用它来处理少数需要的部分，而不是作为通用策略。

4. 4

   映射属性而非组件

   用户关心的是可编辑表面。将每个可编辑道具映射到一个特征或属性，即使底层实现完全是新的，也能保持体验。

   费用： 必须对应物业名称和类型，并重新确立违约情况。

选择GrapesJS的一个优点是可以通过插件扩展编辑器，而不是从零实现所有功能。这些是GJS.Market目录中的真实列表——名称、价格和图片直接来自市场，因此这里没有任何内容偏离实际销售内容。

重建你的组件库

清单步骤1到5。现成的组件和块集，可以从中开始，而不是手写定义每个类型。

浏览本部分

Plugin Basic Blocks

一组基础结构块，作为调色板的起点。

免费查看

GrapesJS Components Farmer

从现有标记生成组件类型。

免费查看

Plugin Forms

输入带有可编辑属性的组件，准备进入特性面板。

免费查看

Users Blocks

这样你的团队可以注册自己的块集，而不用写管道。

¥424.80查看

Craft.js团队手工组装的控制器

清单步骤6。内联富文本编辑，在Craft.js项目中，这几乎总是团队成员编写的组件。

浏览本部分

GrapesJS Inline Text Editor — Compatible with CKEditor 5

将内置文本编辑替换为CKEditor 5。

¥496.80查看

TinyMCE 8 Inline Text Editor

将内置文本编辑功能替换为TinyMCE 6。

¥496.80查看

Froala Inline Text Editor

将内置的文本编辑替换为Froala。

¥496.80查看

Grapesjs RTE Extensions

扩展了内置文本工具栏，增加了更多格式操作。

免费查看

将你的设计系统带入画布

如果你的 React 组件是基于工具或组件框架构建的，同一系统可以支持用户拖入的模块。

浏览本部分

Plugin Blocky for Tailwind CSS

基于Tailwind的模块，符合以公用事业为先的设计系统。

¥424.80查看

Grapesjs Tailwind

在画布内渲染Tailwind类。

免费查看

GrapesJS Bootstrap v5 Blocks

Bootstrap 5 版面布局和内容块。

免费查看

Bootstrap 4 Blocks for GrapesJS

Bootstrap 4 网格和内容块，适用于老旧系统。

免费查看

项目数据与媒体

清单步骤8到10。文档被保存在哪里，上传的媒体去哪里。

浏览本部分

IndexedDB Storage

文档保存在浏览器中——对原型和离线工作非常有用。

免费查看

Cloud Firestore

将项目数据持久化到Cloud Firestore。

免费查看

Grapesjs Firebase Storage

商店上传了Firebase格式的媒体。

免费查看

Grapesjs Cloudinary

使用Cloudinary作为Asset Manager背后的媒体库。

免费查看

这些都是不同的产品，各自有自己的架构指南、权衡和插件。

如果你决定GrapesJS适合，还有第二个选择：是带着现有编辑器过去，还是在旁边新建一个。它们的价格不同。

每行一个需求，一个起始点。其中四个指向Craft.js，这也是其他五个值得一读的原因。

没有万能的赢家。正确的选择取决于你的编辑器架构和产品需求。

GJS.Market 构建并迁移 GrapesJS 编辑器。如果你不想单独完成清单，这些是参与项目涵盖的阶段——第一个阶段是评估，可能会得出继续使用 Craft.js 是正确答案的结论。

如果你现在的编辑器需要太多自定义基础设施，就用实际项目来评估GrapesJS。从编辑器开始，用插件扩展它，并围绕你的产品定制架构。