Plate 插件编写审计指南从真实仓库模式提炼 Slate-first 插件架构规范【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate导读本文围绕 Plate 开源仓库中一份面向插件作者的审计文档plugin-authoring-audit.md展开它从真实仓库中提炼出值得照抄的强模式也标出了需要谨慎对待的历史遗留写法。读完本文你将掌握如何区分语义基座插件src/lib与 Plate/React 包装层src/react何时选用createSlatePlugin/createTSlatePlugin/createPlatePlugin/toPlatePlugin以及为什么共享插件键必须来自KEYS、为什么手动标注SlateEditor回调参数是坏习惯。每一类模式都会给出仓库内真实文件的路径与关键代码片段作为可验证依据。一、审计文档的背景与定位这份审计文档不是一篇独立的架构宣言而是 plate-plugin-creator 技能体系下的执行参照物。整个技能体系分为三层SKILL.md总纲定义了 Slate-first、Plate-second 的硬性法则Hard Law与不要照抄清单creation-flow.md写插件前的决策树回答该用哪个工厂函数typing.md类型契约规范回答如何利用回调上下文而非手搓类型注解composition.md组合与 API 形状规范回答如何扩展正确的表面plugin-authoring-audit.md本文主体用真实仓库文件做正反例清单回答仓库里哪些写法值得复制、哪些要小心。审计文档的核心方法论是不空谈理论而是以真实包为标本——评论、代码块、HTML 序列化、基础块捆绑、选区、AI Copilot 等插件各代表一种架构类型。阅读时应当把模式描述 源码路径 代码片段三者对照。二、值得照抄的强模式Strong Patterns2.1 模式一语义基座插件 薄 Plate 包装层审计文档推荐的第一个标本是 comment 包语义核心BaseCommentPlugin.tsPlate 薄包装CommentPlugin.tsx包装层Plate wrapper整份文件只有三行import { toPlatePlugin } from platejs/react; import { BaseCommentPlugin } from ../lib; export const CommentPlugin toPlatePlugin(BaseCommentPlugin);真正的语义全部沉淀在基座里。基座用createTSlatePluginBaseCommentConfig显式声明契约因为它导出的是真实存在的公共 APIcomment命名空间下挂了一组查询has、node、nodeId、nodes和一组变换removeMark、setDraft、unsetMark。这正是审计文档强调的explicit config type exists because the contract is real——契约真实存在时显式配置类型才有意义。关键实现细节基座通过.overrideEditor(withComment)注入编辑器级行为通过.extendApi(...)与.extendTransforms(...)分别扩展api.comment与tf.comment键来自共享常量KEYS.comment见 plate-keys.ts节点标记isLeaf: true并声明选区规则rules: { selection: { affinity: outward } }。从源码结构看这套基座在src/lib、包装在src/react、契约真实才显式化的三段式是 Plate 仓库内部评论插件一贯的组织方式。2.2 模式二基座插件 Plate 子插件装配第二个标本是 code-block 包基座BaseCodeBlockPlugin.ts包装CodeBlockPlugin.tsx这里的重点在于嵌套子插件的归属语义子插件BaseCodeLinePlugin、BaseCodeSyntaxPlugin直接挂在基座的plugins数组里plugins: [BaseCodeLinePlugin, BaseCodeSyntaxPlugin]因为它们是语义契约的一部分而 React 层的CodeBlockPlugin只用toPlatePlugin把基座提升上来并补上 Plate 子插件装配export const CodeBlockPlugin toPlatePlugin(BaseCodeBlockPlugin, { plugins: [CodeLinePlugin, CodeSyntaxPlugin], });基座自身承载了丰富的语义规则HTML 反序列化parsers: { html: { deserializer: htmlDeserializerCodeBlock } }、空块删除重置rules: { delete: { empty: reset } }、语法高亮装饰decorate lowlight 实例、以及toggle变换。包装层没有重新声明任何语义只负责把已经存在的 Plate 子插件接进来。2.3 模式三纯 Slate 插件就保持 Slate-only第三个标本是 HtmlPlugin.ts——一个没有 React 层的插件。它的职责是把粘贴进来的 HTML 反序列化为 Slate 节点、把 Slate 内容序列化为 HTMLexport const HtmlPlugin createSlatePlugin({ key: html, }) .extendApi(({ editor }) ({ deserialize: bindFirst(deserializeHtml, editor), })) .extend({ parser: { format: text/html, deserialize: ({ api, data }) { const document parseHtmlDocument(data); return api.html.deserialize({ element: document.body }); }, }, });审计文档给它的评价是三点没有虚假的 React 层、语义归属一目了然、createSlatePlugin用得很自然。消费方最终用 React 不等于插件必须从 React 写起这是 Slate-first 法则的直接体现。2.4 模式四捆绑插件直接用 Plate 组合第四个标本是 BasicBlocksPlugin.tsx。它的工作本身就是组合——把已经写好的区块插件打包export const BasicBlocksPlugin createPlatePlugin({ plugins: [BlockquotePlugin, HeadingPlugin, HorizontalRulePlugin], });审计文档特意强调捆绑已有 Plate 插件时不要先发明一个假基座fake base plugin theater。组合就是组合createPlatePlugin是正确工具为它造一个BaseBasicBlocksPlugin只会增加无意义的抽象层。2.5 模式五真正的 React-native Plate 插件有一类插件本质上没有 Slate-only 语义它们天然属于 React/Plate 层。审计文档给了三个标本EventEditorPlugin.ts监听编辑器焦点/失焦事件并写入EventEditorStore通过document.dispatchEvent广播BLUR_EDITOR_EVENT/FOCUS_EDITOR_EVENTPlaywrightPlugin.ts通过useHooks: usePlaywrightAdapter挂测试适配器CopilotPlugin.tsxAI 续写重度依赖 React 渲染层render.belowNodes幽灵文本与浏览器事件onBlur/onMouseDown拒绝建议。以 EventEditorPlugin.ts 为例export const EventEditorPlugin createPlatePlugin({ key: eventEditor, handlers: { onBlur: ({ editor }) { /* 记录 blur 并广播事件 */ }, onFocus: ({ editor }) { /* 记录 focus 并广播事件 */ }, }, });审计文档的点评是它们因为真实原因活在 Plate/React 层而不是假装自己是 Slate-first 语义插件。判断依据很直接——如果剥离 React 后这个插件就没有存在的意义那它就不该硬塞一个基座。2.6 模式六用transformProps做 React-only 属性增强最后一类强模式针对给已渲染节点增强 props的场景推荐inject.nodeProps.transformProps而不是发明包装组件。两个标本BlockSelectionPlugin.tsxNavigationFeedbackPlugin.ts看 NavigationFeedbackPlugin.ts 的实现export const NavigationFeedbackPlugin toTPlatePlugin( NavigationFeedbackBasePlugin, { inject: { isElement: true, nodeProps: { transformProps: ({ element, props, text }) { const activeTarget useNavigationHighlight(element ?? text); if (!activeTarget) return props; return { ...props, data-nav-cycle: String(activeTarget.cycle), data-nav-highlight: activeTarget.variant, data-nav-pulse: String(activeTarget.pulse), data-nav-target: true, style: { ...(props.style ?? {}), --plate-nav-feedback-duration: ${activeTarget.duration}ms, }, }; }, }, }, } );注意transformProps内部直接调用 React HookuseNavigationHighlight这正是它优于普通包装组件的点当增强逻辑需要 Hook 时transformProps让语义基座保持干净同时把 Hook 逻辑留在 Plate 层。BlockSelectionPlugin.tsx 的做法类似通过inject.nodeProps.transformProps返回useBlockSelectable().props给已渲染块注入可选中的 props。审计文档同时也划清了边界transformProps是属性增强工具不是node.component、render、useHooks的通用替代品。真正要替换组件时不要滥用它。三、需要谨慎对待的模式Patterns To Treat Carefully3.1 共享插件键应当来自KEYSplate-keys.ts 是仓库内所有已发布包共用的键表KEYS.comment、KEYS.codeBlock、KEYS.codeLine、KEYS.p、KEYS.textAlign、KEYS.blockSelection等都在这里集中定义。审计文档提醒大多数已发布的包代码已经在依赖KEYS裸字符串字面量会在基座、包装层、测试之间产生漂移drift只有极小的内部插件或有意不建模共享契约的本地测试夹具才适合硬编码字面量。配合 typing.md 的使用方式是key: KEYS.blockSelection targetPlugins: [KEYS.p] editor.getType(KEYS.codeBlock)从源码看这一点在仓库内部执行得很一致上述所有被审计的插件comment、code-block、selection、basic-nodes、playwright、ai无一例外使用KEYS命名键。3.2 手动SlateEditor回调注解老风格别照抄第二个谨慎模式标本是 BaseTextAlignPlugin.tsexport const BaseTextAlignPlugin createSlatePlugin({ key: KEYS.textAlign, inject: { isBlock: true, nodeProps: { /* ... */ }, targetPlugins: [KEYS.p], targetPluginToInject: ({ editor }: { editor: SlateEditor }) ({ /* ... */ }), }, node: { type: align }, }).extendTransforms(({ editor }: { editor: SlateEditor }) ({ setNodes: (value: Alignment, options?: SetNodesOptions) setAlign(editor, value, options), }));审计文档的评价是它能工作但属于老风格教坏习惯——回调上下文本身已经注入editor手动标注{ editor }: { editor: SlateEditor }纯属噪音。除非类型推断真的失败、且没有更好的显式契约可用此时应该上createT*或导出真正的PluginConfig别名否则不要照抄这种写法。typing 规则中明确把它列为usually noise, not help的反例。3.3 编辑器锁定的辅助函数抽取第三个谨慎模式标本是 BaseAIPlugin.ts。它内部抽取了getAITransforms(editor: SlateEditor)把一批bindFirst(transform, editor)打包返回const getAITransforms (editor: SlateEditor) ({ acceptPreview: bindFirst(acceptAIPreview, editor), beginPreview: bindFirst(beginAIPreview, editor), cancelPreview: bindFirst(cancelAIPreview, editor), discardPreview: bindFirst(discardAIPreview, editor), hasPreview: bindFirst(hasAIPreview, editor), insertNodes: bindFirst(insertAINodes, editor), removeMarks: bindFirst(removeAIMarks, editor), removeNodes: bindFirst(removeAINodes, editor), undo: bindFirst(undoAI, editor), }); export const BaseAIPlugin createTSlatePluginBaseAIPluginConfig({ key: KEYS.ai, node: { isDecoration: false, isLeaf: true }, }) .extendTransforms(({ editor }) getAITransforms(editor)) .extendEditorTransformsBaseAIPluginConfig[transforms](({ editor }) ({ ai: getAITransforms(editor), }));审计文档的立场很微妙这种抽取可行但它会鼓励把编辑器在线程里传来传去的模式而新的回调上下文 APIeditor、plugin、type、api、tf、getOptions、setOption等往往让这种线程化变得没必要。优先使用上下文局部context-local的辅助函数或更好的泛型形状再考虑复制这种做法。composition 规则也给出了底线单次使用、上下文局部的辅助函数就内联要抽取就让它泛型化、尽量无上下文依赖不要习惯性地锁死SlateEditor。四、与上游规则文档的衔接审计文档不是孤立的它与技能体系的其余部分形成闭环。写新插件时应按以下顺序消费这些资料先走 creation-flow.md 的决策树行为是否依赖 React需要显式公共契约吗是捆绑插件吗——据此决定用createSlatePlugin/createTSlatePlugin/createPlatePlugin/createTPlatePlugin再对照本文审计文档找最接近的真实标本语义基座看 comment/code-block纯 Slate 看 html捆绑看 basic-nodesReact-native 看 event-editor/playwright/copilotReact-only 增强看 block-selection/navigation-feedback类型与契约细节看 typing.md优先推断、用上下文、共享键走KEYS、extendApi/extendEditorApi要选对车道组合与 API 形状看 composition.md基座优先包装其次、嵌套插件放对层、configurePlugin优于手抄配置、transformProps只用于属性增强。SKILL.md 还强调了一个文件放置硬规则永远不要手写或手改index.ts/index.tsx桶文件视为生成物增删导出文件后运行pnpm brl非公共契约的辅助代码默认放internal/目录。五、结语把审计清单当作写插件的对照表这份审计文档的最终价值是给插件作者一张可照抄/要小心对照表场景照抄的标本关键动作有真实语义 需要 ReactBaseCommentPlugin.ts CommentPlugin.tsx基座在src/lib包装用toPlatePlugin语义基座带子插件BaseCodeBlockPlugin.ts CodeBlockPlugin.tsx语义子插件挂基座Plate 子插件挂包装纯序列化/解析逻辑HtmlPlugin.ts保持 Slate-only不建 React 层只是捆绑已有插件BasicBlocksPlugin.tsxcreatePlatePlugin({ plugins: [...] })不造假基座无 Slate 语义的 React 集成EventEditorPlugin.ts、PlaywrightPlugin.ts、CopilotPlugin.tsx直接用createPlatePlugin/createTPlatePluginReact-only 属性增强BlockSelectionPlugin.tsx、NavigationFeedbackPlugin.ts优先inject.nodeProps.transformProps需要共享键plate-keys.ts用KEYS.*避免字面量漂移谨慎对待的三件事同样重要不要在推断可用时手动标注SlateEditor回调参数见 BaseTextAlignPlugin.ts 的老风格不要为了迁就 TypeScript 而抽取编辑器锁定的辅助函数见 BaseAIPlugin.ts 的取舍不要把transformProps当万能胶水。始终以核心插件 API 与类型测试为最高事实来源而不是以最响亮的旧文件为准。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Plate 插件编写审计指南：从真实仓库模式提炼 Slate-first 插件架构规范
Plate 插件编写审计指南从真实仓库模式提炼 Slate-first 插件架构规范【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate导读本文围绕 Plate 开源仓库中一份面向插件作者的审计文档plugin-authoring-audit.md展开它从真实仓库中提炼出值得照抄的强模式也标出了需要谨慎对待的历史遗留写法。读完本文你将掌握如何区分语义基座插件src/lib与 Plate/React 包装层src/react何时选用createSlatePlugin/createTSlatePlugin/createPlatePlugin/toPlatePlugin以及为什么共享插件键必须来自KEYS、为什么手动标注SlateEditor回调参数是坏习惯。每一类模式都会给出仓库内真实文件的路径与关键代码片段作为可验证依据。一、审计文档的背景与定位这份审计文档不是一篇独立的架构宣言而是 plate-plugin-creator 技能体系下的执行参照物。整个技能体系分为三层SKILL.md总纲定义了 Slate-first、Plate-second 的硬性法则Hard Law与不要照抄清单creation-flow.md写插件前的决策树回答该用哪个工厂函数typing.md类型契约规范回答如何利用回调上下文而非手搓类型注解composition.md组合与 API 形状规范回答如何扩展正确的表面plugin-authoring-audit.md本文主体用真实仓库文件做正反例清单回答仓库里哪些写法值得复制、哪些要小心。审计文档的核心方法论是不空谈理论而是以真实包为标本——评论、代码块、HTML 序列化、基础块捆绑、选区、AI Copilot 等插件各代表一种架构类型。阅读时应当把模式描述 源码路径 代码片段三者对照。二、值得照抄的强模式Strong Patterns2.1 模式一语义基座插件 薄 Plate 包装层审计文档推荐的第一个标本是 comment 包语义核心BaseCommentPlugin.tsPlate 薄包装CommentPlugin.tsx包装层Plate wrapper整份文件只有三行import { toPlatePlugin } from platejs/react; import { BaseCommentPlugin } from ../lib; export const CommentPlugin toPlatePlugin(BaseCommentPlugin);真正的语义全部沉淀在基座里。基座用createTSlatePluginBaseCommentConfig显式声明契约因为它导出的是真实存在的公共 APIcomment命名空间下挂了一组查询has、node、nodeId、nodes和一组变换removeMark、setDraft、unsetMark。这正是审计文档强调的explicit config type exists because the contract is real——契约真实存在时显式配置类型才有意义。关键实现细节基座通过.overrideEditor(withComment)注入编辑器级行为通过.extendApi(...)与.extendTransforms(...)分别扩展api.comment与tf.comment键来自共享常量KEYS.comment见 plate-keys.ts节点标记isLeaf: true并声明选区规则rules: { selection: { affinity: outward } }。从源码结构看这套基座在src/lib、包装在src/react、契约真实才显式化的三段式是 Plate 仓库内部评论插件一贯的组织方式。2.2 模式二基座插件 Plate 子插件装配第二个标本是 code-block 包基座BaseCodeBlockPlugin.ts包装CodeBlockPlugin.tsx这里的重点在于嵌套子插件的归属语义子插件BaseCodeLinePlugin、BaseCodeSyntaxPlugin直接挂在基座的plugins数组里plugins: [BaseCodeLinePlugin, BaseCodeSyntaxPlugin]因为它们是语义契约的一部分而 React 层的CodeBlockPlugin只用toPlatePlugin把基座提升上来并补上 Plate 子插件装配export const CodeBlockPlugin toPlatePlugin(BaseCodeBlockPlugin, { plugins: [CodeLinePlugin, CodeSyntaxPlugin], });基座自身承载了丰富的语义规则HTML 反序列化parsers: { html: { deserializer: htmlDeserializerCodeBlock } }、空块删除重置rules: { delete: { empty: reset } }、语法高亮装饰decorate lowlight 实例、以及toggle变换。包装层没有重新声明任何语义只负责把已经存在的 Plate 子插件接进来。2.3 模式三纯 Slate 插件就保持 Slate-only第三个标本是 HtmlPlugin.ts——一个没有 React 层的插件。它的职责是把粘贴进来的 HTML 反序列化为 Slate 节点、把 Slate 内容序列化为 HTMLexport const HtmlPlugin createSlatePlugin({ key: html, }) .extendApi(({ editor }) ({ deserialize: bindFirst(deserializeHtml, editor), })) .extend({ parser: { format: text/html, deserialize: ({ api, data }) { const document parseHtmlDocument(data); return api.html.deserialize({ element: document.body }); }, }, });审计文档给它的评价是三点没有虚假的 React 层、语义归属一目了然、createSlatePlugin用得很自然。消费方最终用 React 不等于插件必须从 React 写起这是 Slate-first 法则的直接体现。2.4 模式四捆绑插件直接用 Plate 组合第四个标本是 BasicBlocksPlugin.tsx。它的工作本身就是组合——把已经写好的区块插件打包export const BasicBlocksPlugin createPlatePlugin({ plugins: [BlockquotePlugin, HeadingPlugin, HorizontalRulePlugin], });审计文档特意强调捆绑已有 Plate 插件时不要先发明一个假基座fake base plugin theater。组合就是组合createPlatePlugin是正确工具为它造一个BaseBasicBlocksPlugin只会增加无意义的抽象层。2.5 模式五真正的 React-native Plate 插件有一类插件本质上没有 Slate-only 语义它们天然属于 React/Plate 层。审计文档给了三个标本EventEditorPlugin.ts监听编辑器焦点/失焦事件并写入EventEditorStore通过document.dispatchEvent广播BLUR_EDITOR_EVENT/FOCUS_EDITOR_EVENTPlaywrightPlugin.ts通过useHooks: usePlaywrightAdapter挂测试适配器CopilotPlugin.tsxAI 续写重度依赖 React 渲染层render.belowNodes幽灵文本与浏览器事件onBlur/onMouseDown拒绝建议。以 EventEditorPlugin.ts 为例export const EventEditorPlugin createPlatePlugin({ key: eventEditor, handlers: { onBlur: ({ editor }) { /* 记录 blur 并广播事件 */ }, onFocus: ({ editor }) { /* 记录 focus 并广播事件 */ }, }, });审计文档的点评是它们因为真实原因活在 Plate/React 层而不是假装自己是 Slate-first 语义插件。判断依据很直接——如果剥离 React 后这个插件就没有存在的意义那它就不该硬塞一个基座。2.6 模式六用transformProps做 React-only 属性增强最后一类强模式针对给已渲染节点增强 props的场景推荐inject.nodeProps.transformProps而不是发明包装组件。两个标本BlockSelectionPlugin.tsxNavigationFeedbackPlugin.ts看 NavigationFeedbackPlugin.ts 的实现export const NavigationFeedbackPlugin toTPlatePlugin( NavigationFeedbackBasePlugin, { inject: { isElement: true, nodeProps: { transformProps: ({ element, props, text }) { const activeTarget useNavigationHighlight(element ?? text); if (!activeTarget) return props; return { ...props, data-nav-cycle: String(activeTarget.cycle), data-nav-highlight: activeTarget.variant, data-nav-pulse: String(activeTarget.pulse), data-nav-target: true, style: { ...(props.style ?? {}), --plate-nav-feedback-duration: ${activeTarget.duration}ms, }, }; }, }, }, } );注意transformProps内部直接调用 React HookuseNavigationHighlight这正是它优于普通包装组件的点当增强逻辑需要 Hook 时transformProps让语义基座保持干净同时把 Hook 逻辑留在 Plate 层。BlockSelectionPlugin.tsx 的做法类似通过inject.nodeProps.transformProps返回useBlockSelectable().props给已渲染块注入可选中的 props。审计文档同时也划清了边界transformProps是属性增强工具不是node.component、render、useHooks的通用替代品。真正要替换组件时不要滥用它。三、需要谨慎对待的模式Patterns To Treat Carefully3.1 共享插件键应当来自KEYSplate-keys.ts 是仓库内所有已发布包共用的键表KEYS.comment、KEYS.codeBlock、KEYS.codeLine、KEYS.p、KEYS.textAlign、KEYS.blockSelection等都在这里集中定义。审计文档提醒大多数已发布的包代码已经在依赖KEYS裸字符串字面量会在基座、包装层、测试之间产生漂移drift只有极小的内部插件或有意不建模共享契约的本地测试夹具才适合硬编码字面量。配合 typing.md 的使用方式是key: KEYS.blockSelection targetPlugins: [KEYS.p] editor.getType(KEYS.codeBlock)从源码看这一点在仓库内部执行得很一致上述所有被审计的插件comment、code-block、selection、basic-nodes、playwright、ai无一例外使用KEYS命名键。3.2 手动SlateEditor回调注解老风格别照抄第二个谨慎模式标本是 BaseTextAlignPlugin.tsexport const BaseTextAlignPlugin createSlatePlugin({ key: KEYS.textAlign, inject: { isBlock: true, nodeProps: { /* ... */ }, targetPlugins: [KEYS.p], targetPluginToInject: ({ editor }: { editor: SlateEditor }) ({ /* ... */ }), }, node: { type: align }, }).extendTransforms(({ editor }: { editor: SlateEditor }) ({ setNodes: (value: Alignment, options?: SetNodesOptions) setAlign(editor, value, options), }));审计文档的评价是它能工作但属于老风格教坏习惯——回调上下文本身已经注入editor手动标注{ editor }: { editor: SlateEditor }纯属噪音。除非类型推断真的失败、且没有更好的显式契约可用此时应该上createT*或导出真正的PluginConfig别名否则不要照抄这种写法。typing 规则中明确把它列为usually noise, not help的反例。3.3 编辑器锁定的辅助函数抽取第三个谨慎模式标本是 BaseAIPlugin.ts。它内部抽取了getAITransforms(editor: SlateEditor)把一批bindFirst(transform, editor)打包返回const getAITransforms (editor: SlateEditor) ({ acceptPreview: bindFirst(acceptAIPreview, editor), beginPreview: bindFirst(beginAIPreview, editor), cancelPreview: bindFirst(cancelAIPreview, editor), discardPreview: bindFirst(discardAIPreview, editor), hasPreview: bindFirst(hasAIPreview, editor), insertNodes: bindFirst(insertAINodes, editor), removeMarks: bindFirst(removeAIMarks, editor), removeNodes: bindFirst(removeAINodes, editor), undo: bindFirst(undoAI, editor), }); export const BaseAIPlugin createTSlatePluginBaseAIPluginConfig({ key: KEYS.ai, node: { isDecoration: false, isLeaf: true }, }) .extendTransforms(({ editor }) getAITransforms(editor)) .extendEditorTransformsBaseAIPluginConfig[transforms](({ editor }) ({ ai: getAITransforms(editor), }));审计文档的立场很微妙这种抽取可行但它会鼓励把编辑器在线程里传来传去的模式而新的回调上下文 APIeditor、plugin、type、api、tf、getOptions、setOption等往往让这种线程化变得没必要。优先使用上下文局部context-local的辅助函数或更好的泛型形状再考虑复制这种做法。composition 规则也给出了底线单次使用、上下文局部的辅助函数就内联要抽取就让它泛型化、尽量无上下文依赖不要习惯性地锁死SlateEditor。四、与上游规则文档的衔接审计文档不是孤立的它与技能体系的其余部分形成闭环。写新插件时应按以下顺序消费这些资料先走 creation-flow.md 的决策树行为是否依赖 React需要显式公共契约吗是捆绑插件吗——据此决定用createSlatePlugin/createTSlatePlugin/createPlatePlugin/createTPlatePlugin再对照本文审计文档找最接近的真实标本语义基座看 comment/code-block纯 Slate 看 html捆绑看 basic-nodesReact-native 看 event-editor/playwright/copilotReact-only 增强看 block-selection/navigation-feedback类型与契约细节看 typing.md优先推断、用上下文、共享键走KEYS、extendApi/extendEditorApi要选对车道组合与 API 形状看 composition.md基座优先包装其次、嵌套插件放对层、configurePlugin优于手抄配置、transformProps只用于属性增强。SKILL.md 还强调了一个文件放置硬规则永远不要手写或手改index.ts/index.tsx桶文件视为生成物增删导出文件后运行pnpm brl非公共契约的辅助代码默认放internal/目录。五、结语把审计清单当作写插件的对照表这份审计文档的最终价值是给插件作者一张可照抄/要小心对照表场景照抄的标本关键动作有真实语义 需要 ReactBaseCommentPlugin.ts CommentPlugin.tsx基座在src/lib包装用toPlatePlugin语义基座带子插件BaseCodeBlockPlugin.ts CodeBlockPlugin.tsx语义子插件挂基座Plate 子插件挂包装纯序列化/解析逻辑HtmlPlugin.ts保持 Slate-only不建 React 层只是捆绑已有插件BasicBlocksPlugin.tsxcreatePlatePlugin({ plugins: [...] })不造假基座无 Slate 语义的 React 集成EventEditorPlugin.ts、PlaywrightPlugin.ts、CopilotPlugin.tsx直接用createPlatePlugin/createTPlatePluginReact-only 属性增强BlockSelectionPlugin.tsx、NavigationFeedbackPlugin.ts优先inject.nodeProps.transformProps需要共享键plate-keys.ts用KEYS.*避免字面量漂移谨慎对待的三件事同样重要不要在推断可用时手动标注SlateEditor回调参数见 BaseTextAlignPlugin.ts 的老风格不要为了迁就 TypeScript 而抽取编辑器锁定的辅助函数见 BaseAIPlugin.ts 的取舍不要把transformProps当万能胶水。始终以核心插件 API 与类型测试为最高事实来源而不是以最响亮的旧文件为准。【免费下载链接】plateRich-text editor with AI and shadcn/ui项目地址: https://gitcode.com/GitHub_Trending/pl/plate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
