Slate v2 / Plate v2 对比架构研究：Plate 仓库的约束驱动型编辑器架构调研方法论与结论

Slate v2 / Plate v2 对比架构研究：Plate 仓库的约束驱动型编辑器架构调研方法论与结论

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate

导读

本文基于 docs/plans/2026-04-03-slate-v2-plate-v2-comparative-research-plan.md 展开，系统讲解 Plate 项目如何通过"分阶段架构对照研究"打磨下一代编辑器：先敲定slate-v2的最佳方案，再规划未来的plate-v2架构。文章完整继承了研究计划的锁定约束、研究顺序、捕获规则与完成条件，并结合仓库内 架构研究账本、缺口矩阵、架构契约 与 packages/slate 源码，给出 16 个参考仓库/规范的全部研究结论与"下一步证明"建议。读完本文，你将理解：为什么这类研究必须是"约束内提炼"而非市场地图，如何用统一的分类词汇把零散灵感沉淀成可执行的架构决策，以及 Clipboard 边界证明为何成为slate-v2结构性下一步。

研究定位：这不是市场地图，也不是仓库观光

研究计划的 Goal 一节把这次调研的性质界定得非常清楚：在编辑器与编辑器之外的候选参考中做分阶段架构研究，目标优先级是——

1. 先拿出绝对最好的slate-v2方案；
2. 再规划未来的plate-v2架构。

它明确排除了两种常见跑偏：这不是市场地图（market map），也不是仓库观光（repo sightseeing）。研究的意义被浓缩为一句话：只提取那些能经受住既定约束检验的想法（"extract only the ideas that survive contact with our locked constraints"）。

这一立场贯穿了整个计划的设计：先锁定不可动摇的前提，再让外部参考接受前提的检验，而不是反过来让外部潮流改写前提。对应仓库中 editor-architecture-candidates.md 的表述——候选清单"是有观点的短名单，不是市场地图，也不是每个 GitHub 编辑器仓库的墓地"。

锁定约束：研究不可重新发现的六条前提

研究计划要求：以下约束已经决定，研究不应"重新发现"它们。这六条约束构成整个slate-v2的架构宪法，也是评估一切外部想法的筛选器：

1. slate-v2保持数据模型优先（data-model-first）：文档模型是核心，渲染与交互围绕模型展开，而非由 DOM 反向决定。
2. 操作（Operations）保持外部一等公民：协作与历史所需的操作流必须继续作为公开、可序列化的实体存在。
3. 事务（Transactions）是内部执行模型：引擎内部的写入以事务批处理为默认执行方式，而非逐操作裸变更。
4. 运行时所有权保持拆分，落在四个独立包上：
   • slate-v2：核心模型与事务；
   • slate-dom-v2：DOM 桥接层；
   • slate-react-v2：React 运行时；
   • slate-history-v2：历史/撤销重做。
5. slate-react-v2明确面向 React19.2+，按 React-perfect 意图设计。
6. 团队明确偏好上述权衡，而非 headless-first 的纯粹性或 React 18 的兼容广度。

因此研究计划的提问方式也随之确定：不是问"Slate 是否应该再次变成框架无关的"，而是问——

• 哪些包级与运行时技术能够强化已选定的方向？
• 哪些内容更应当留给未来的plate-v2，而不是塞进slate-v2？

这些约束在仓库后续文档中得到了一致贯彻。架构契约 中明确写出：slate-react是参考运行时（reference runtime）而非事后适配器，目标"不是把 React 塞进核心，而是一个不再与 React 对抗的更好的核心"；slate-v2 总览 也确认了四个包的分工与 React 19.2.5 基线。从 packages/slate/src 的实际结构看，核心包内也的确为 DOM 与历史预留了独立边界（slate-dom.ts、slate-history/目录），与"运行时所有权拆分"的约束相互印证。

研究产出物：持续更新的四类文档

研究不是一次性报告，而是持续喂养四条文档线。计划规定研究应持续更新：

1. editor-architecture-candidates.md：候选名单及其排序理由——为什么是这个顺序。
2. slate-v2-plate-v2-architecture-research.md：有用想法的累积账本（cumulative ledger）。
3. slate-v2-gap-matrix.md：尚未解决的结构层与产品层缺口。
4. docs/slate-v2：只有当某个发现足够强、足以收紧当前计划时，才写入正式路线文档。

这条产出链路在仓库中已实际落地：研究账本长达 1700 余行，按仓库逐条记录发现与分类；缺口矩阵用"状态键 + 属主包 + 证据 + 参考仓库 + 归属"的结构管理每个未解缺口；master-roadmap.md 则是路线图的权威队列来源（研究计划自己也注明"当前队列与路线图真相请以 master-roadmap 为准"）。

捕获规则：八个考察桶与四种结论分类

计划为每个被研究仓库/参考规定了统一的捕获桶（capture buckets），共八类：

1. 核心引擎（Core engine）
2. DOM 桥（DOM bridge）
3. React 运行时（React runtime）
4. 历史（History）
5. 剪贴板 / 外部格式（Clipboard / external formats）
6. 插件 / 扩展模型（Plugin / extension model）
7. 产品 / DX / 打包（Product / DX / packaging）
8. 布局 / 组合 / 分页（Layout / composition / pagination）

同时，每个想法必须被精确归类为以下四者之一，不允许停留在"可能有用"的模糊状态：

• adopt-now-for-slate-v2（现在采纳进 slate-v2）
• adopt-later-for-slate-v2（稍后采纳进 slate-v2）
• better-fit-for-plate-v2（更适合 plate-v2）
• interesting-but-reject（有趣但拒绝）

这套双轴分类（考察维度 × 结论归属）的价值在于：它强迫研究者在每个发现上都做出明确决策，避免"灵感收集癖"。研究账本中每个仓库的每一节都严格遵循"发现 → 分类 → 理由"三段式，例如 edix 的 React 示例被评为interesting-but-reject（"适合小 demo，但不是比 selector-first 的 slate-react-v2 更好的渲染器架构"）。

此外，计划要求：每一个主要的未解决 Slate 压力区（pressure area）都要同步录入缺口矩阵，附带——属主包（owner package）、issue 证据（issue evidence）、证明状态（proof status）、最佳参考仓库（best reference repos）、以及预期归属（slate-v2 now/later还是plate-v2）。缺口矩阵 正是按此实现的，例如"剪贴板片段所有权与外部格式边界"被标记为structural-next，属主为slate-dom-v2+slate-v2，参考仓库为 ProseMirror、edix、Tiptap，归属为adopt-now-for-slate-v2。

分阶段研究顺序：从基线到跨领域导入

研究顺序本身是计划的精华：它按"对当前方案的打磨价值"排序，而不是按名气或热度。共六个阶段：

Phase 0：当前基线（Current Baseline）

先盘点自己已经证明的东西——

• 当前slate-v2证明栈（proof stack）；
• 当前包拆分与证明结果；
• 已完成的edix研究。

目的：精确知道已经证明了什么，避免对比工作去解决已经解决的问题。这是"不重复造轮子"的工程化体现。

Phase 1：继承与基准基线（Inheritance And Benchmark Baseline）

1. Slate—— 理解我们正在从 Slate 继承什么；
2. ProseMirror—— 与纪律最严明的编辑器架构直接对比。

Phase 2：运行时架构压力（Runtime Architecture Pressure）

3. Lexical—— 考察运行时/更新/身份/渲染纪律；
4. Tiptap—— 考察产品化、扩展 UX 与打包策略。

Phase 3：布局与组合未来（Layout And Composition Futures）

5. Pretext—— 确定性文本测量原语；
6. Premirror—— 文档真相之上的分页组合引擎。

目的：决定哪些属于未来slate-v2，哪些更适合作为plate-v2或更高层系统。

Phase 4：轻量表面压力（Lightweight Surface Pressure）

7. use-editable；
8. rich-textarea；
9. markdown-editor。

目的：检验"完整包栈在哪些场景是杀鸡用牛刀"，识别更适合 Plate 自持轻量表面（而非 Slate 核心/运行时）的想法。

Phase 5：跨领域架构导入（Cross-Domain Architecture Imports）

10. TanStack DB—— 投影（projections）与索引；
11. urql—— 管道/交换架构（pipeline/exchange）；
12. VS Code—— 语义服务边界；
13. Language Server Protocol—— 协议化外部智能；
14. EditContext API—— 未来平台输入原语；
15. Open UI Richer Text Fields—— 未来平台富文本字段方向。

这一阶段把视野扩展到编辑器之外，体现了计划的真实野心：下一代编辑器架构的养分不只来自编辑器。

工作规则：Slate 优先的三问

计划设置了一条硬性工作规则（Working Rule）：Slate 是优先级。因此每一轮研究都必须按此顺序回答：

1. 什么能直接改进slate-v2？
2. 什么有用但更适合推迟到plate-v2？
3. 什么看起来聪明但应当拒绝？

若某个发现主要帮助plate-v2，保留它，但不允许它扭曲slate-v2的包计划。这条规则与锁定约束共同构成了研究的方法论防火墙：外部灵感只能作为输入，不能作为推翻既定架构方向的理由。这与 架构契约 中的"原则栈"完全一致——data-model-first → operation/collaboration-friendly → transaction-first → React-optimized runtime → optional adapters，顺序即优先级。

完成条件：研究何时算结束

计划定义了清晰的完成条件（Done Condition）：

1. 短名单中的每个候选都有清晰的账本条目；
2. slate-v2文档集反映了最强的直接发现；
3. 剩余想法被明确分拣到三个槽位：slate-v2 now、slate-v2 later、plate-v2；
4. 能够带着真正的信心对slate-v2做最后一轮打磨——而不是出于"对流行仓库的眼红"（fashionable repo-envy）。

研究结论：16 个参考全部完成后的最强直接下一步

计划末尾的 Progress 节记录了 2026-04-03 当天的执行结果：全部 16 个候选（edix、ProseMirror、Lexical、Tiptap、Pretext、Premirror、use-editable、rich-textarea、markdown-editor、TanStack DB、urql、VS Code、LSP、EditContext API、Open UI Richer Text Fields，加 Slate 作为基线）均已完成研究，并沉淀出如下结论。

最强直接下一步：Clipboard 边界证明

研究给出的"最强直接下一步含义"第一条就是：先做 clipboard-boundary 证明，并保持包拆分不变。原因从账本中可清晰看到：ProseMirror、edix、Lexical 三个参考在剪贴板归属上高度一致——剪贴板应拥有自己明确的边界。其中 ProseMirror 是最强参考：剪贴板位于其view包而非核心状态，序列化/解析是显式函数，且通过data-pm-slice这样的显式内部元数据避免格式意外泄漏，并提供transformCopied、clipboardSerializer、transformPastedHTML、transformPasted等一整套变换钩子。

这条结论在仓库中已经落地为正式计划：2026-04-03-slate-v2-clipboard-boundary-proof-plan.md。该计划进一步明确了职责切分：slate-v2只承担最小片段语义（selected-fragment 提取 + 一个显式片段插入原语 + 替换语义），slate-dom-v2负责自定义 MIME 键、DataTransfer、HTML 抓取、纯文本导出等浏览器传输；同时诚实标注规模——涉及约 10-14 个文件，跨核心代码、DOM 代码与测试，"6-8 个文件是幻想"。

分仓库核心结论（账本精华）

研究账本对每个参考给出了八个桶的逐项发现与分类，以下是各参考的"摘要级"结论：

• Slate：状态为covered-in-baseline。当前slate-v2规划已直接来自 Slate 继承压力与 issue 语料，不再花时间做广义考古。
• ProseMirror：对包拆分的最强外部验证。model / transform / state / view / history / collab的分包纪律、持久不可变的EditorState、一等公民的Transaction、history包用结构化的选择书签（selection bookmarks）与显式事件分组，都被评为adopt-now-for-slate-v2或adopt-later-for-slate-v2。结论："它不会改变我们的 React 运行时方向，但让包架构看起来更加正确。"
• Lexical：对"专用运行时包 + 不可变编辑器状态 + 显式更新语义 + 剪贴板/历史独立成包"的最强验证。其HISTORY_MERGE_TAG/HISTORY_PUSH_TAG/HISTORIC_TAG标签词汇是后续事务元数据的精炼目标（adopt-later-for-slate-v2）；但其基于useState+useLayoutEffect的useLexicalSubscription被拒绝——不如slate-react-v2选定的useSyncExternalStore+ React 19.2+ 方向。
• Tiptap：@tiptap/pm单依赖 ProseMirror 封装、干净 React 包、海量扩展目录被评为better-fit-for-plate-v2。结论："Tiptap 的快主要来自把 ProseMirror 打包得极好，这对 plate-v2 意义重大，对 slate-v2 意义很小——别把产品打包的胜利误当成引擎/运行时胜利。"
• Pretext：prepare(...)/layout(...)两阶段、用 canvas 测量 + 缓存校准绕开 DOM reflow 的确定性测量原语，主要归属未来布局/分页/虚拟化层（better-fit-for-plate-v2），并支持adopt-later-for-slate-v2的布局提示价值。
• Premirror：最强的"分页归属上层"证据。UnmeasuredDocumentSnapshot → MeasuredDocumentSnapshot → LayoutInput → LayoutOutput → MappingIndex契约把文档真相、测量、组合、渲染拆成独立层；分页、widow/orphan 控制、帧与障碍物都属于composer包。结论："Premirror 不是更好的 Slate，而是'页面感知编辑应构建为文档真相 + 测量 + 组合 + 渲染/叠加'的最佳证据。"
• edix：无头命令式核心 + 微任务事务队列 + DOM 选择快照序列化 + 显式internalCopy/internalPaste，是适配器与剪贴板参考（DOM 桥与剪贴板均adopt-now-for-slate-v2），但不是渲染器蓝图也不是历史蓝图。
• use-editable：单个 hook + 变更回滚 + 选择修复的极简下界（lower bound），归better-fit-for-plate-v2；其 DOM 持有真相 + 变更回滚的方式与锁定约束直接冲突，被interesting-but-reject。
• rich-textarea：最强轻量表面参考——真实<textarea>为输入真相 + 镜像背景层做高亮/装饰，ResizeObserver+ 克隆鼠标事件避免 contenteditable 混乱。结论："如果问题是纯文本加装饰，用原生文本控件叠加视觉层，别把完整 Slate 栈拖进这种问题。"
• markdown-editor：基于unified的 markdown 投影层，但手工 DOM 计数、字符数不变式、display:block破坏布局等约束使其脆弱，被评为"警告多于蓝图"；其教训是轻量表面应偏向rich-textarea式原生控件叠加，而非脆弱的 contenteditable 投影。
• TanStack DB：归一化集合、显式索引、实时查询编译为增量数据流管道（@tanstack/db-ivm）、薄框架绑定，是"未来 plate-v2 语义层"的最强参考（投影/索引/派生视图），对 slate-v2 只是后期导入而非核心转向。
• urql：bindings → client → exchanges的事件中枢 + 操作/结果管道，是"交换/中间件"架构的最佳参考。硬规则（不丢弃未知操作、同步优先/异步置后排序）应影响未来语义与扩展架构，而非基础运行时。
• VS Code：文本模型与渲染分离、模型经协议同步到 worker、按特性注册表（per-feature registry）而非单一巨型插件接口、显式 RPC 边界、特性延迟的一等公民处理。结论是"不复制 VS Code，而是学：用按特性注册表、显式隔离宿主/进程边界、按特性类型适配 provider"。
• LSP：语义服务应说"文档、位置、编辑、诊断、能力"这类中立原语，而不是编辑器内部节点模型；一次性初始化 + 能力协商、版本化文档同步、拉取式诊断、completionItem/resolve惰性解析、取消与ContentModified处理，构成未来 plate-v2 语义服务的协议参考。
• EditContext API：真实但非魔法。它能将文本输入与 DOM 变更解耦（textupdate/textformatupdate/beforeinput），但不自动解决选择映射、拼写检查、剪贴板/拖放、无障碍与撤销。定位为后期slate-dom-v2输入接缝候选（adopt-later-for-slate-v2）与未来自定义表面工具。
• Open UI Richer Text Fields：InputRange()范围提取、原生文本字段 CSS 高亮、建议/幽灵文本、输入掩码四大主题，是"轻量表面走原生控件"的最强平台方向；若落地，许多rich-textarea式表面会大幅简化，更多场景应完全留在 Slate 之外。

对后续架构的四条定性结论

2026-04-03 的进度记录还给出了四条方向性结论：

• 不要基于 ProseMirror 或 Lexical 重新思考 React 运行时——slate-react-v2的useSyncExternalStore+ React 19.2+ 方向维持不变；
• 但后续要挖掘 Lexical 的 update-tag 与 extension-graph 想法（分别对应缺口矩阵中的"更新元数据/脏信号纪律"与"插件/扩展架构"两条research-next缺口）；
• 分页、确定性测量与页面组合保持在slate-v2之上——Pretext 视为测量原语，Premirror 视为未来 plate-v2 / 更高层架构参考，而不是给 Slate 核心注水的理由；
• 未来plate-v2语义架构更应接近 TanStack DB + urql：归一化投影存储、增量派生视图、类 exchange 的执行阶段；语义特性按能力宿主（参考 VS Code 的按特性注册表），语义服务说 LSP 式的中立原语。

从研究计划到可运行架构：与仓库当前状态的衔接

研究计划的产出并非停留在纸面。它通过三条链路与仓库当前代码状态咬合：

1. 缺口矩阵驱动证明顺序：slate-v2-gap-matrix.md 将剪贴板片段所有权列为唯一的structural-next缺口（"这是下一个缺失的 Phase 4 接缝"），并注明"已证明项"包括：slate-v2事务优先核心、slate-dom-v2身份背书 DOM 查找与包含、slate-react-v2selector-first 运行时与受控替换、slate-history-v2事务感知撤销单元——这些与锁定约束逐条对应。
2. 架构契约给出可读写的运行时形状：架构契约 展示的editor.read/editor.update公共运行时契约正是"事务为内部执行模型"的外化：

editor.read(() => { editor.getSelection(); editor.getChildren(); }); editor.update(() => { editor.unwrapNodes({ match: isList }); editor.setNodes({ type: "list-item" }); editor.wrapNodes({ type: "bulleted-list", children: [] }); });

规则包括：editor.read是连贯读边界，editor.update是写边界，原语编辑器方法是灵活变更 API，扩展通过命名editor/state/tx组组合，Transforms.*不再是主要公开变更故事，可变成员字段不是主要读路径。

3. 核心包源码呼应拆分承诺：packages/slate/src 中create-editor.ts、index.ts、interfaces/、internal/、slate-dom.ts、slate-history/的布局，以及 master-roadmap.md 中 Tranche 3 对editor.read/editor.update/ 原语方法 / 扩展editor、state、tx组 / commit 订阅者的"规范公共运行时层级"的定案，都表明研究结论已经进入实现执行阶段。

结语：方法论比结论更值得带走

回顾这份研究计划，最有价值的其实不是"该抄哪个仓库"，而是它展示的一套可复用的架构研究方法：先锁定不可谈判的前提 → 用统一的八桶四类词汇捕获发现 → 按对当前方案的打磨价值排序研究顺序 → 用"Slate 优先"的三问过滤灵感 → 以账本、缺口矩阵、候选清单持续喂养决策。这套方法让 16 个外部参考的调研既没有滑向"市场观光"，也没有变成"流行仓库复读机"，最终收敛出一个清晰的下一步——clipboard-boundary 证明，以及一个更清晰的判断：分页与语义服务属于未来的plate-v2，而slate-v2的使命是把数据模型、操作、事务与 React-perfect 运行时这条主线做透。

【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate