最近一直在折腾编辑器相关的功能。

原本以为，编辑器这种东西，选一个成熟方案接上去，能输入、能加粗、能插图片，差不多就算交差了。可项目一往业务深处走，才慢慢发现，编辑器从来不是一个单纯的“写字区域”，它更像一个内容操作台。用户表面上是在写字，实际上是在组织信息、标记信息、加工信息、流转信息。

我这边当前使用的大致技术栈就是前端比较常见的一套：**TypeScript** 做开发语言，编辑器用的是 **wangeditor**。之所以选这套，一方面是 TypeScript 写起来边界清楚，后期维护心里踏实；另一方面是 wangeditor 本身扩展性不错，不只是能满足基础富文本输入，做一些定制化菜单、自定义元素、插件能力也比较顺手。

事情的起因，也并不复杂。

一开始，我们的内容录入场景只是“把文字输进去”。后来业务一点点长肉，需求也开始变得具体起来。用户不只是写内容，他们还要对内容里的某些片段做进一步处理。比如一段话里，某几个词可能是某个实体；某一小段内容可能需要标记成一个特殊标签；某个选中的文本片段，点击之后需要弹出一个面板，去补充更多业务信息。

换句话说，项目已经不满足于“写进去”，而是希望编辑器里的文本能携带更多结构化语义。

这个时候我就发现，编辑器默认提供的那套按钮其实不太够用了。

加粗、斜体、下划线、标题、引用，这些当然都很常见，也很实用。但在我们的场景里，用户更真实的诉求是：**我选中一段文字之后，想马上给它设置一个标签。**

这个动作很像人在纸质文稿上拿笔圈出一段内容，然后在旁边写一个注释。  
只是到了富文本编辑器里，这个动作要变成菜单、选区、弹窗、配置，以及一整套编辑器扩展机制。

于是，我就开始动手给 wangeditor 加一个自定义菜单按钮。

说实话，这种时候会有一种很奇妙的感觉。编辑器原本像一个规规矩矩的老员工，只会做默认配置里那些事；你现在要亲手教它一个新技能，让它从“会排版”进化到“懂业务”。这件事本身就挺有意思的。

这次要做的目标非常明确：

- 用户选中一段文字
- 工具栏里出现一个“设置标签”的按钮
- 点击这个按钮
- 弹出业务弹窗
- 弹窗拿到当前选中的文字
- 后续由业务层完成标签设置

如果再进一步，这个功能还可以出现在 hoverbar 里。这样当用户选中文字的时候，不需要专门去顶部工具栏找按钮，能力会自己飘到手边，体验会更自然。

我很喜欢这种交互方式。  
它不是让用户去适应系统，而是让系统尽量贴近用户的操作直觉。

下面就是当时写下的核心代码。我这里直接原样放出来，不做改动。

```typescript
import { DomEditor, IButtonMenu, IDomEditor, ISelectMenu } from '@wangeditor/editor'

export class MentionMenu implements IButtonMenu {
  constructor() {
    this.title = '设置标签'
    // this.iconSvg = '<svg >...</svg>'
    this.tag = 'button'
  }

  title: string
  iconSvg?: string | undefined
  hotkey?: string | undefined
  alwaysEnable?: boolean | undefined
  tag: string
  width?: number | undefined

  getValue(editor: IDomEditor) {
    return editor.getSelectionText()
  }

  isActive(editor: IDomEditor) {
    return false // or true
  }

  isDisabled(editor: IDomEditor) {
    return !editor.getSelectionText() // or true
  }

  exec(editor: IDomEditor, value: string | boolean) {
    // if (typeof value === 'string') editor.insertText(value)
    triggerModal(editor, undefined, editor.getSelectionText())
  }
}
```

现在回过头看，这段代码其实很像一个刚刚被安排进编辑器体系里的“新角色”。

它的名字叫 `MentionMenu`，实现的是 `IButtonMenu`。也就是说，它不是一个复杂控件，它就是一个按钮，一个很纯粹的动作入口。

在构造函数里，我给了它一个标题：`设置标签`。  
这个名字非常直给，因为业务本身也不需要绕弯子。用户看见这个按钮，就应该立刻明白它是干什么的。

`tag = 'button'` 这一句也很干脆，它告诉编辑器：把我当按钮处理。

真正有意思的是后面这几个方法。

`getValue(editor)` 返回的是 `editor.getSelectionText()`。当时写这里的时候，我脑子里想得很清楚：这个菜单不是围绕某种格式状态存在的，它的全部意义都建立在“当前选中了什么文本”这件事上。它不关心字号，不关心颜色，不关心段落结构，它只关心用户手里到底框住了哪一段内容。

`isActive(editor)` 这里我直接返回了 `false`。因为这个按钮本质上不是那种“有激活态”的菜单。像加粗、斜体这种菜单，选中对应格式内容时，它们会呈现一种“我当前生效中”的状态。但“设置标签”不是这样，它更像一个动作型按钮，负责发起一次业务行为，而不是表达当前文本状态。

`isDisabled(editor)` 这里就很关键了：

```typescript
isDisabled(editor: IDomEditor) {
  return !editor.getSelectionText() // or true
}
```

这句几乎可以说是这个按钮的脾气。

用户如果没有选中文本，那按钮就应该安静待着，不要乱出头。  
因为没有选区，“设置标签”这件事在语义上就不成立。总不能对空气打标签。  
所以只要没有选中文本，它就禁用自己。

我一直觉得，一个好的交互不只是“能点”，还应该知道“什么时候不该点”。  
这一句虽然小，但它让整个按钮的行为边界变得很清楚。

然后就是最核心的 `exec`：

```typescript
exec(editor: IDomEditor, value: string | boolean) {
  // if (typeof value === 'string') editor.insertText(value)
  triggerModal(editor, undefined, editor.getSelectionText())
}
```

点击按钮之后，直接触发 `triggerModal`，并把当前选中的文本传进去。

这一步在业务上就非常自然了。  
因为真正复杂的标签配置、属性填写、确认逻辑，其实不应该塞在菜单按钮本身里。菜单只是入口，弹窗才是承载业务交互的地方。按钮负责敲门，弹窗负责接待，数据跟着选区一起进去，后面的流程就能顺着走下去。

当然，光有这个类还不够。  
编辑器不是说你写了个类，它就自动认识你。你还得把它郑重其事地注册进去，告诉整个 wangeditor 体系：“从今天开始，这位新同事正式入职了。”

所以接下来就是模块配置。

这部分代码我同样原样贴出来：

```typescript
/**
 * @description mention module entry
 * @author wangfupeng
 */

import { IModuleConf } from '@wangeditor/editor'
import { AutoSelectMenu, MentionMenu, withMention } from './plugin'
import renderElemConf from './render-elem'
import elemToHtmlConf from './elem-to-html'
import parseHtmlConf from './parse-elem-html'

const module: Partial<IModuleConf> = {
  editorPlugin: withMention,
  renderElems: [renderElemConf],
  elemsToHtml: [elemToHtmlConf],
  parseElemsHtml: [parseHtmlConf],
  menus: [
    {
      key: 'mention-set',
      factory() {
        return new MentionMenu()
      },
    }
  ],
}

export default module
```

这段配置在我看来，很像一份正式的人事档案。

前面那些 `editorPlugin`、`renderElems`、`elemsToHtml`、`parseElemsHtml`，都说明这个功能并不只是表面加一个按钮那么简单。它其实是和一整套 mention 能力绑定在一起的：编辑器插件怎么工作、自定义元素怎么渲染、怎么转成 HTML、HTML 又怎么重新解析回来，这些都是同一个生态里的事情。

而对我这次需求来说，最关键的是 `menus` 这一段。

这里通过一个 `key: 'mention-set'`，把这个菜单正式命名。  
这个 key 很重要，后面不管是工具栏配置，还是 hoverbar 配置，引用的都是它。  
然后通过 `factory()` 返回一个新的 `MentionMenu` 实例。

到这一步，编辑器才算真正认识了这个按钮。

不过事情还没完。

因为实际使用过程中，我越来越觉得，光把这个按钮放在固定工具栏里还不够顺手。  
用户在编辑文本的时候，注意力主要都在内容区，不一定愿意频繁抬头去看工具栏。  
尤其是“设置标签”这种动作，本身就是围绕选区发生的，那它最合适出现的位置，应该是离选区最近的地方。

所以后来又把它往 `hoverbar` 里接了一下。

这部分配置如下，我也原样放出来：

```typescript
editor.getConfig().hoverbarKeys['text'].menuKeys.unshift('mention-set')
    insertKeys = {
      index: 0,
      keys: ['mention-set', 'auto-select'],
}
```

这一段接上之后，交互就一下子灵了很多。

`editor.getConfig().hoverbarKeys['text'].menuKeys.unshift('mention-set')` 这句的意思很直白，就是把 `mention-set` 插到文本 hoverbar 的菜单队列最前面。也就是说，当 hoverbar 围绕文本出现的时候，“设置标签”这个按钮优先露脸。

我当时特别喜欢 `unshift` 这个动作。  
它不是温吞吞地排到后面，而是直接往前站。  
像一个业务上非常重要的能力，理直气壮地走到舞台中央。

后面的 `insertKeys` 也是同样的思路：

```typescript
insertKeys = {
  index: 0,
  keys: ['mention-set', 'auto-select'],
}
```

这里我把 `mention-set` 和 `auto-select` 放在一起，其实也是因为它们在交互上很搭。

如果编辑器里已经有“自动选择句子”之类的能力，那么“设置标签”跟它放在一起，会特别像一套连贯动作：

- 先智能选中内容
- 再立刻提供标签能力
- 用户几乎不用费额外力气

这时候编辑器的感觉就不再像一个生硬的输入工具，而有点像一个会察言观色的助手了。

我后来反复在心里琢磨，为什么这种自定义菜单会让人觉得很值。

原因大概在于，编辑器的价值，从来不只是“把文字显示出来”。  
真正复杂的内容系统，最终都要面对一个问题：如何让文本承载业务语义。  
而自定义菜单，就是把业务语义接到编辑过程里的桥。

用户不是写完之后再去别处处理，  
而是在写的当下，就能直接对内容做结构化动作。  
这种一气呵成的感觉，对业务效率和体验都很重要。

现在回头看，这段代码其实不算长，逻辑也不算特别复杂。  
但它背后的动机非常真实：  
不是为了炫技，不是为了给编辑器“加点花活”，而是因为业务走到了那个阶段，真的需要这样一个能力入口。

我很喜欢这种从场景里长出来的代码。  
它不是空中楼阁，不是为了写而写，而是你真的看见了用户在某个地方停顿、犹豫、来回操作，然后你决定给这个动作修一条更顺的路。

于是，就有了这个“设置标签”按钮。

它只是一个菜单。  
但它也是编辑器从“会写字”走向“懂业务”的一步。

原本以为，编辑器这种东西，选一个成熟方案接上去，能输入、能加粗、能插图片，差不多就算交差了。可项目一往业务深处走，才慢慢发现，编辑器从来不是一个单纯的“写字区域”，它更像一个内容操作台。用户表面上是在写字，实际上是在组织信息、标记信息、加工信息、流转信息。

给编辑器加一个设置标签按钮：wangeditor 自定义菜单实战

技术副总监/联合创始人

前端

探索富文本编辑器的业务化改造：基于wangeditor实现"设置标签"功能。通过TypeScript开发自定义菜单按钮，将业务逻辑融入编辑流程，支持文本选区标记、结构化语义处理。详细解析菜单注册、hoverbar集成等核心代码实现，提升编辑器与业务场景的契合度，让文本编辑更智能高效。

TypeScript

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

给编辑器加一个设置标签按钮：wangeditor 自定义菜单实战-腾讯云开发者社区-腾讯云

给编辑器加一个设置标签按钮：wangeditor 自定义菜单实战

给编辑器加一个设置标签按钮：wangeditor 自定义菜单实战

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐