Lexical 图片处理 5 步走从拖拽到上服务器的完整链路【免费下载链接】lexicalLexical is an extensible text editor framework that provides excellent reliability, accessibility and performance.项目地址: https://gitcode.com/GitHub_Trending/le/lexical产品提了个需求用户把 4K 原图拖进富文本编辑器自动压缩、裁成 16:9移动端还不能撑破布局。做过编辑器的人都清楚这条链路里每一环都可能翻车。Lexical 图片处理这件事绕不开的核心其实只有一句图片在文档里只是一个 URL 加尺寸剩下的压缩、裁剪、上传全是这个 URL 落地之前的事。产品需求拆开图片在 Lexical 里只是一个 URL先看需求拆解原图进编辑器入口、压缩裁剪预处理、移动端适配渲染、刷新后还在持久化。Lexical 对图片的态度和 Word 完全不同——它不提供图片控件只提供节点机制。图片是 DecoratorNode节点存数据decorate()返回的 React 组件负责渲染两者互不干涉。class ImageNode extends DecoratorNode { decorate() { return ImageComponent src{this.__src} width{this.__width} ... /; } }这段是 playground 里 ImageNode 的骨架关键在__src、__width这些字段——它们会被exportJSON写进文档而渲染细节懒加载、加载失败兜底全在组件侧。官方示例里图片节点长这样选中后会出现缩放手柄让图片能被选中、缩放、拖动图显示出来只是第一步用户下一步一定会拖它。选中图片时选区是节点选区而不是文字选区useLexicalNodeSelection(nodeKey)拿到选中态后挂工具条。缩放由组件里的ImageResizer处理拖拽结束才调node.setWidthAndHeight(width, height)把结果写回节点——拖动过程中不碰节点只在结束时更新一次。移动图片则走 Lexical 的命令系统DRAGSTART_COMMAND里把节点的 JSON 序列化塞进dataTransfer自定义类型application/x-lexical-drag落地时解析出来重新插入。这里有个容易忽略的点拖拽搬运的是节点数据不是图片二进制交互逻辑和节点逻辑通过命令完全解耦你的上传插件也能复用同一套。把本地 dataURL 换成服务器 URLdemo 阶段很多人像 playground 的上传弹窗那样用FileReader.readAsDataURL把图片读成 base64 直接塞进节点。真实项目里这撑不过第三个迭代编辑器状态会进历史记录、会走协同通道塞一张 base64 就是往状态里灌几 MB 字符串undo 一次复制一次。生产链路上本地临时地址到服务器 URL 的替换必须发生在INSERT_IMAGE_COMMANDdispatch 之前。节点里永远只存 URLconst { url } await uploadImage(file); // 校验、压缩、上传 editor.dispatchCommand(INSERT_IMAGE_COMMAND, { src: url, altText });整条链路不长handler 侧做的事很少在 playground 的ImagesExtension里可以看到editor.registerCommand(INSERT_IMAGE_COMMAND, payload { const imageNode $createImageNode(payload); $insertNodes([imageNode]); if ($isRootOrShadowRoot(imageNode.getParentOrThrow())) { $wrapNodeInElement(imageNode, $createParagraphNode).selectEnd(); } return true; }, COMMAND_PRIORITY_EDITOR);关键是命令是图片进入文档的唯一入口——URL 对话框、拖放、粘贴导入三种方式最后都汇到这。文档持久化URL 必须稳定尺寸必须进 JSONeditorState.toJSON()出来的文档里图片节点只有src、altText、width、height、maxWidth。两个推论URL 必须稳定。CDN 地址、带哈希或内容寻址的路径换掉域名就是全库死链没有补救余地。宽高要存进节点。列表视图、缩略图都靠它撑布局不存的话图片加载完布局才定下来页面会跳一下。导出 HTML 时exportDOM会把src、alt、width、height一起带出去figure figcaption的图注结构也是在这里拼的。节点结构在 DevTools 里长这样落地时容易踩的 4 个点粘贴导入会夹带私货HTML 里带file:///路径的img要过滤掉Google Docs 的列表勾选标记也是img不认出来会粘出一堆碎图。playground 的ImgRule里这两个判断都写了值得抄。加载失败要有兜底playground 用一个 Promise 缓存加载状态失败后渲染BrokenImage占位而不是让img裸奔。裁剪你自己接Lexical 不做裁剪canvas 前端裁或云存储图片处理都行产物是 URL接在上传那步之前即可。别动maxWidth它控制渲染上限移动端不撑破布局基本靠它配合同比例的宽高换算。继续深入的话按这个顺序看源码节点字段和 JSON 序列化在 packages/lexical-playground/src/nodes/ImageNode.tsx选中、缩放和懒加载在 ImageComponent.tsx插入命令、拖放和粘贴规则在 ImagesExtension协同编辑场景看 packages/lexical-yjs 目录。【免费下载链接】lexicalLexical is an extensible text editor framework that provides excellent reliability, accessibility and performance.项目地址: https://gitcode.com/GitHub_Trending/le/lexical创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Lexical 图片处理 5 步走：从拖拽到上服务器的完整链路
Lexical 图片处理 5 步走从拖拽到上服务器的完整链路【免费下载链接】lexicalLexical is an extensible text editor framework that provides excellent reliability, accessibility and performance.项目地址: https://gitcode.com/GitHub_Trending/le/lexical产品提了个需求用户把 4K 原图拖进富文本编辑器自动压缩、裁成 16:9移动端还不能撑破布局。做过编辑器的人都清楚这条链路里每一环都可能翻车。Lexical 图片处理这件事绕不开的核心其实只有一句图片在文档里只是一个 URL 加尺寸剩下的压缩、裁剪、上传全是这个 URL 落地之前的事。产品需求拆开图片在 Lexical 里只是一个 URL先看需求拆解原图进编辑器入口、压缩裁剪预处理、移动端适配渲染、刷新后还在持久化。Lexical 对图片的态度和 Word 完全不同——它不提供图片控件只提供节点机制。图片是 DecoratorNode节点存数据decorate()返回的 React 组件负责渲染两者互不干涉。class ImageNode extends DecoratorNode { decorate() { return ImageComponent src{this.__src} width{this.__width} ... /; } }这段是 playground 里 ImageNode 的骨架关键在__src、__width这些字段——它们会被exportJSON写进文档而渲染细节懒加载、加载失败兜底全在组件侧。官方示例里图片节点长这样选中后会出现缩放手柄让图片能被选中、缩放、拖动图显示出来只是第一步用户下一步一定会拖它。选中图片时选区是节点选区而不是文字选区useLexicalNodeSelection(nodeKey)拿到选中态后挂工具条。缩放由组件里的ImageResizer处理拖拽结束才调node.setWidthAndHeight(width, height)把结果写回节点——拖动过程中不碰节点只在结束时更新一次。移动图片则走 Lexical 的命令系统DRAGSTART_COMMAND里把节点的 JSON 序列化塞进dataTransfer自定义类型application/x-lexical-drag落地时解析出来重新插入。这里有个容易忽略的点拖拽搬运的是节点数据不是图片二进制交互逻辑和节点逻辑通过命令完全解耦你的上传插件也能复用同一套。把本地 dataURL 换成服务器 URLdemo 阶段很多人像 playground 的上传弹窗那样用FileReader.readAsDataURL把图片读成 base64 直接塞进节点。真实项目里这撑不过第三个迭代编辑器状态会进历史记录、会走协同通道塞一张 base64 就是往状态里灌几 MB 字符串undo 一次复制一次。生产链路上本地临时地址到服务器 URL 的替换必须发生在INSERT_IMAGE_COMMANDdispatch 之前。节点里永远只存 URLconst { url } await uploadImage(file); // 校验、压缩、上传 editor.dispatchCommand(INSERT_IMAGE_COMMAND, { src: url, altText });整条链路不长handler 侧做的事很少在 playground 的ImagesExtension里可以看到editor.registerCommand(INSERT_IMAGE_COMMAND, payload { const imageNode $createImageNode(payload); $insertNodes([imageNode]); if ($isRootOrShadowRoot(imageNode.getParentOrThrow())) { $wrapNodeInElement(imageNode, $createParagraphNode).selectEnd(); } return true; }, COMMAND_PRIORITY_EDITOR);关键是命令是图片进入文档的唯一入口——URL 对话框、拖放、粘贴导入三种方式最后都汇到这。文档持久化URL 必须稳定尺寸必须进 JSONeditorState.toJSON()出来的文档里图片节点只有src、altText、width、height、maxWidth。两个推论URL 必须稳定。CDN 地址、带哈希或内容寻址的路径换掉域名就是全库死链没有补救余地。宽高要存进节点。列表视图、缩略图都靠它撑布局不存的话图片加载完布局才定下来页面会跳一下。导出 HTML 时exportDOM会把src、alt、width、height一起带出去figure figcaption的图注结构也是在这里拼的。节点结构在 DevTools 里长这样落地时容易踩的 4 个点粘贴导入会夹带私货HTML 里带file:///路径的img要过滤掉Google Docs 的列表勾选标记也是img不认出来会粘出一堆碎图。playground 的ImgRule里这两个判断都写了值得抄。加载失败要有兜底playground 用一个 Promise 缓存加载状态失败后渲染BrokenImage占位而不是让img裸奔。裁剪你自己接Lexical 不做裁剪canvas 前端裁或云存储图片处理都行产物是 URL接在上传那步之前即可。别动maxWidth它控制渲染上限移动端不撑破布局基本靠它配合同比例的宽高换算。继续深入的话按这个顺序看源码节点字段和 JSON 序列化在 packages/lexical-playground/src/nodes/ImageNode.tsx选中、缩放和懒加载在 ImageComponent.tsx插入命令、拖放和粘贴规则在 ImagesExtension协同编辑场景看 packages/lexical-yjs 目录。【免费下载链接】lexicalLexical is an extensible text editor framework that provides excellent reliability, accessibility and performance.项目地址: https://gitcode.com/GitHub_Trending/le/lexical创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考