Electrolux_blog
Search K

Appearance

目录

高频问题与参考回答 ​

1. Tiptap 和 ProseMirror 的关系是什么？ ​

答法：
Tiptap 不是替代 ProseMirror，而是其上层框架。ProseMirror 提供文档模型、事务、插件机制；Tiptap 提供扩展系统、命令 API、框架绑定（React/Vue）和更易用的工程化能力。

2. 为什么 Tiptap 采用 Headless 设计？ ​

答法：
编辑器 UI 与业务耦合非常重。Headless 让状态/行为与 UI 解耦，企业可以接入自己的设计系统，不被默认样式束缚，也更适合多端一致性。

3. 讲讲扩展系统是怎么工作的？ ​

答法（结构化）：

  1. 扩展通过 Extension/Node/Mark 声明能力。
  2. ExtensionManager 负责 resolve/sort，生成 schema、commands、plugins、nodeViews。
  3. 编辑器事件与扩展生命周期 hook 统一绑定。
  4. 扩展顺序由 priority 与 manager 逻辑控制。

4. commands、chain、can 的区别？ ​

答法：

  • commands：直接执行并 dispatch。
  • chain：多个命令共用同一 tr，run() 一次提交。
  • can：无副作用模拟，判断能否执行。

5. React 集成为什么复杂？ ​

答法：
因为要同时解决实例稳定性、事务驱动更新、SSR/StrictMode、NodeView 桥接。
Tiptap 用 EditorInstanceManager + useSyncExternalStore + EditorContent portals 来控制这些边界。

6. SSR 下 immediatelyRender 为什么重要？ ​

答法：
编辑器依赖 DOM。SSR 若立即渲染容易 hydration mismatch。
因此 SSR 常设 immediatelyRender: false，CSR 可设 true 获得更直接实例行为。相关背景见 #5856 与 PR #5161。

7. 协同场景为什么要禁用普通 undo/redo？ ​

答法：
协同扩展已引入 Yjs 的 UndoManager。若再叠加本地 history，会有双历史源冲突。
因此协同扩展会警告不兼容，并通过命令元数据控制 dispatch 行为。

8. Markdown 方案为什么不是“直接字符串编辑”？ ​

答法：
编辑器内部真相源必须是结构化文档树，才能支持 selection、transform、协同、NodeView。
Markdown 在 Tiptap 是输入/输出格式，通过扩展注册 parse/render 与 schema 对齐。

9. 如果让你优化大文档性能，你会怎么做？ ​

答法（可落地）：

  1. React 层使用 useEditorState(selector) 降低订阅粒度。
  2. 避免菜单类组件因未 memo props 触发插件重建。
  3. 复杂 NodeView 提供自定义 update diff。
  4. 减少无关 update 事件（善用 preventUpdate）。
  5. 检查输入规则/粘贴规则正则复杂度与触发频率。

10. 你会如何设计一个“@提及 + #标签 + /命令”统一输入系统？ ​

答法：

  • 基于 Suggestion 建三组 trigger（@/#//），每组独立 pluginKey 与 items。
  • 用 shouldShow(transaction) 过滤协同远端事件。
  • 在 Mention attrs 中保存触发字符（类似 mentionSuggestionChar）保证序列化可逆。
  • 与 Markdown tokenizer 对齐，保证导入导出一致。

11. 哪些是 Tiptap 常见线上坑？ ​

  • 多实例 unmount 误删样式（#6836）。
  • SSR + immediatelyRender 配置错误（#5856）。
  • BubbleMenu/FloatingMenu props 更新与插件重建回归（#6963 / #7028 / #7115）。
  • 协同与本地历史并用导致行为异常。

12. 在直接使用 Tiptap 时，有哪些最佳实践与错误用例对照？ ​

答法（最佳实践 vs 错误用例）：

  1. React 渲染隔离

    • 最佳实践：把编辑器和依赖 editor 的 UI（菜单、状态按钮）隔离在独立组件，避免被页面其他状态（侧边栏、主题切换）带着重渲染；配合 useEditorState(selector) 只订阅必要字段。
    • 错误用例：把 useEditor 放在页面根组件，任何无关 state 变化都触发编辑器相关组件重渲染，出现输入卡顿或菜单抖动。

  2. SSR 配置要显式

    • 最佳实践：SSR 场景显式设置 immediatelyRender: false，并在客户端再渲染 EditorContent。
    • 错误用例：把 useEditor 和 EditorProvider 混用，或者在 SSR 下没显式处理 immediatelyRender，导致 hydration mismatch/行为异常（见 #5856、#5161）。

  3. 多实例生命周期管理

    • 最佳实践：多编辑器页面要验证“销毁一个实例不影响其他实例”的样式与交互；升级时关注核心样式注入/移除逻辑。
    • 错误用例：默认认为实例彼此完全隔离，结果某实例卸载后全局注入样式被移除，剩余编辑器样式失效（#6836，修复见 #7109）。

  4. 扩展配置链路保持简单、可测试

    • 最佳实践：对 extend()/configure() 组合写最小回归测试，尤其是 addProseMirrorPlugins、this.parent() 相关扩展。
    • 错误用例：复杂继承链反复 configure，触发重复插件注册或钩子重复执行（#4981、#4257，修复主线见 #5147 / #5156）。

  5. 命令插入与规则联动要谨慎

    • 最佳实践：insertContent(..., { applyInputRules/applyPasteRules }) 只在明确需要“模拟输入/粘贴语义”时开启，并在文末、特殊规则（如高亮 ==...==）场景做边界测试。
    • 错误用例：无差别开启 applyPasteRules，在部分规则下触发 RangeError 或位置映射异常（能力引入见 #5046，问题样本见 #5176）。

  6. BubbleMenu/FloatingMenu 的 props 稳定性

    • 最佳实践：传入的函数和 options 尽量 memo 化，减少插件反复卸载/重建风险；升级时回看 release note 的回归修复。
    • 错误用例：每次 render 都生成新函数/新对象，导致菜单插件反复重建、事务增多甚至选区异常（#6963、#7028、#7115）。

可引用证据（可顺手标注来源）：

13. 30 秒总结版本（最终收口） ​

Tiptap 的价值不在“做个富文本”，而在于它把 ProseMirror 的底层能力工程化成了可组合平台：
扩展系统统一能力注入，命令系统统一事务语义，React/Vue 层处理生命周期边界，协同和 Markdown 作为一等能力持续演进。

MIT License.

Copyright © 2023～present Electrolux