WindRunnerMax

本文介绍了RAG（Retrieval-Augmented Generation）技术在自然语言处理中的应用。RAG通过结合检索和生成技术，有效提升了问答、代码生成等任务的准确性和专业性。文章重点探讨了RAG中文本向量化处理的关键环节，特别是数据分片策略：包括固定长度分片、基于句段分片和基于结构分片三种方式，分析了各自的优缺点及适用场景。作者指出当前RAG服务已较为成熟，但仍需根据具体需求选择合适的分片策略，通过重叠分片等方式优化检索效果。文章最后实现了一个基础RAG示例，展示了文本向量化和检索的核心流程。

本文介绍了浏览器选区与编辑器选区模型的同步实现。基于Range和Selection对象设计了两种选区模型(RawRange和Range)，并探讨了如何建立DOM选区与编辑器选区的关联关系。文章详细分析了选区同步的四种主要挑战：文本节点选区处理、非文本节点选区处理、选区状态标记以及浏览器事件兼容。作者提出通过双向转换机制实现选区同步，并分享了实现过程中的关键见解，包括参考quill和slate的设计思路、使用WeakMap优化节点映射等。该项目已开源，提供了在线演示和相关技术文档链接。

本文探讨了富文本编辑器选区模型的设计实现，重点对比了Quill、Slate和Lexical三种主流编辑器的数据结构与选区表达方式。选区模型的设计直接影响编辑器变更操作的效率，并分析了不同数据结构在遍历查找和应用变更时的优劣。

本文探讨了富文本编辑器中选区模型的设计与实现，重点分析了基于浏览器原生Range和Selection对象的选区操作机制。文章指出选区模型直接决定了编辑器操作范围的表现，并通过示例展示了Quill和Slate两种编辑器在选区表达上的差异。详细解析了Range对象的属性和方法（如setStart、getBoundingClientRect等），以及如何通过Selection对象处理用户选区交互。最后介绍了利用::highlight伪元素实现文本高亮的方法，为富文本编辑器的选区功能开发提供了实践指导。

在富文本编辑器中，序列化与反序列化是非常重要的环节，其涉及到了编辑器的内容复制、粘贴、导入导出等模块。当用户在编辑器中进行复制操作时，富文本内容会被转换为标准的HTML格式，并存储在剪贴板中。而在粘贴操作中，编辑器则需要将这些HTML内容解析并转换为编辑器的私有JSON结构，以便于实现跨编辑器内容的统一管理。

我们使用Git来管理项目的时候，可能会提交一些Blob的二进制文件，这些文件并不能像文本文件一样采用diff delta的形式进行版本控制。如果这些文件一直跟随master的主版本，那么就是属于有效的文件。然而很多时候这些二进制文件会被删除重建，那么由于Git的特性，这些文件会一直留在Git的历史记录中，这样会导致Git仓库变得庞大，不利于版本控制和迁移。最直观的就是clone的时候会很慢，而使用--depth=1则无法看到历史提交的代码。

在这里我们基于Immer和OT-JSON设计了一套应用状态管理方案，通过Immer的草稿机制简化不可变数据操作，结合OT-JSON的原子化操作与协同算法，实现原子化、可协同、高扩展的应用级状态管理方案，以及按需渲染的视图性能优化方案。整体来说，这个方案比较适用于嵌套数据结构的动态组合与状态管理。在实际应用中，我们还是需要根据场景来选择合适的状态管理方案。在应用级别的场景中，例如富文本、画板、低代码中，顶层的架构设计还是非常重要的，所有的状态变更、节点类型都应该由这层架构设计扩展出来。

在本文我们聊了很多关于富文本编辑器基础能力的实现，特别是在DOM结构表现和数据结构之间的设计。并且在浏览器交互的方案上，我们也聊了Canvas实现方案的特点，简单总结了当前成熟产品以及开源编辑器，并且描述了相关实现的优缺点。在后边我们会基于实现基本的富文本编辑器，首先对于整体的架构设计，以及数据结构的操作做概述。然后开始分别实现具体的模块，例如输入模块、剪贴板模块、选区模块等等。

在这里我们主要讨论了Node节点与Path路径映射，即如何确定渲染出的节点处于文档数据定义中的位置，这是slate中实现数据变更时的重要表达，特别是在仅使用选区无法实现的复杂操作中，并且还分析了slate源码来探究了相关问题的实现。那么在后面的文章中，我们延续当前提到的表格但单元格位置的查找，来聊聊表格模块的设计及交互。

在这里我们就依然在轻量级DOM的基础上，讨论了Canvas中描边与填充的绘制问题，以及的实现方式，然后我们实现了基本的选中绘制以及拖拽多选的交互设计，并且实现了Hover的效果，以及拖拽节点的移动。那么在后边我们可以聊一下fillRule规则设计、按需绘制图形节点，也可以聊到更多的交互设计，例如Resize的交互设计、参考线能力的实现、富文本的绘制方案等等。

在这里我们主要讨论了slate中的decoration装饰器的实现，以及在实际使用中可能会遇到的问题，主要是在跨节点的情况下，我们需要将range拆分为多个range，然后分别进行处理，并且还分析了源码来探究了相关问题的实现。那么在后边的文章中我们就主要聊一聊在slate中Path的表达，以及在React中是如何控制其内容表达与正确维护Path路径与Element内容渲染的方案。

在这里我们更专注于文档编辑器的数据结构设计，聊聊基于slate实现的文档编辑器类型系统。在slate中还有很多额外的概念和操作需要关注，例如RangeOperationEditorElementPath等，那么在后边的文章中我们就主要聊一聊在slate中Path的表达，以及在React中是如何控制其内容表达与正确维护Path路径与Element内容渲染的，并且我们还可以聊一聊表格模块的设计与实现。

在这里我们聊到了WrapNode数据结构与操作变换，主要是对于嵌套类型的数据结构需要关注的内容，而实际上节点的类型还可以分为很多种，我们在大范围上可以有BlockNodeTextNode，在BlockNode中我们又可以划分出BaseNodeWrapNodePairNodeVoidNode等，因此文中叙述的内容还是属于比较基本的，在slate中还有很多额外的概念和操作需要关注，例如RangeOperationEditorElementPath等。那么在后边的文章中我们就主要聊一聊在slate中Path。

在我们的在线文档系统中，除了基础的富文本编辑能力外，搜索替换的算法同样也是重要的功能实现。纯文本搜索替换算法相对来说是比较容易实现的，而在富文本的场景中，由于存在图文混排、嵌入模块如Mention等，实现这一功能则相对要复杂得不少。那么本文则以Quill实现的富文本编辑器为基础，通过设计索引查找和图层渲染的方式来实现搜索替换。

在这里我们就依然在轻量级DOM的基础上，讨论了Canvas中描边与填充的绘制问题，以及的实现方式，然后我们实现了基本的选中绘制以及拖拽多选的交互设计，并且实现了Hover的效果，以及拖拽节点的移动。那么在后边我们可以聊一下fillRule规则设计、按需绘制图形节点，也可以聊到更多的交互设计，例如Resize的交互设计、参考线能力的实现、富文本的绘制方案等等。

是一种驻留在用户浏览器后台的脚本，能够拦截和处理网络请求，从而实现丰富的离线体验、缓存管理和网络效率优化。请求拦截是其关键功能之一，通过监听fetch事件，可以捕获所有向网络发出的请求，并有选择地处理这些请求，例如从缓存中读取响应，或者对请求进行修改和重定向，进而实现可靠的离线浏览和更快速的内容加载。

在这里我们聊了聊如何抽象基本的图形绘制以及状态的管理，因为我们的需求在这里所以我们的图形绘制能力会设计的比较简单，而状态管理则是迭代了三个方案才确定通过轻量DOM的方式来实现，那么再往后，我们就需要聊一聊如何实现 层级渲染与事件管理 的能力设计。

Webpack是现代化的静态资源模块化管理和打包工具，其能够通过插件配置处理和打包多种文件格式，生成优化后的静态资源，核心原理是将各种资源文件视为模块，通过配置文件定义模块间的依赖关系和处理规则，从而实现模块化开发。Webpack提供了强大的插件和加载器系统，支持了代码分割、热加载和代码压缩等高效构建能力，显著提升了开发效率和性能。是Webpack中用于解析模块路径的配置项，其负责告诉Webpack如何查找和确定模块的位置，核心功能是通过配置来定义模块的查找机制和优先级，从而确保Webpack。

浏览器扩展的开发还是比较复杂的一件事，特别是在需要兼容v2和v3的情况下，很多设计都需要思考是否能够正常在v3上实现，在v3的浏览器扩展上失去了很多灵活性，但是相对也获取了一定的安全性。不过浏览器扩展本质上的权限还是相当高的，例如即使是v3我们仍然可以在Chrome上使用来实现很多事情，扩展能做的东西实在是太多了，如果不了解或者不开源的话根本不敢安装，因为扩展权限太高可能会造成很严重的例如用户信息泄漏等问题，即使是比如像Firefox那样必须要上传源代码的方式来加强审核，也很难杜绝所有的隐患。

Chrome扩展是一种可以在浏览器中添加新功能和修改浏览器行为的软件程序，我们可以基于Manifest规范的API实现对于浏览器和Web页面在一定程度上的修改，例如广告拦截、代理控制等。则是Chrome浏览器提供的一套与浏览器进行交互的API，我们可以基于DevTools协议控制Chromium内核的浏览器进行各种操作，例如操作页面元素、模拟用户交互等。

静态站点生成是一种在构建时生成静态HTML等文件资源的方法，其可以完全不需要服务端的运行，通过预先生成静态文件，实现快速的内容加载和高度的安全性。由于其生成的是纯静态资源，便可以利用CDN等方案以更低的成本和更高的效率来构建和发布网站，在博客、知识库、API文档等场景有着广泛应用。

虚拟滚动是一种优化长列表性能的技术，其通过按需渲染列表项来提高浏览器运行效率。具体来说，虚拟滚动只渲染用户浏览器视口部分的文档数据，而不是整个文档结构，其核心实现根据可见区域高度和容器的滚动位置计算出需要渲染的列表项，同时不渲染额外的视图内容。虚拟滚动的优势在于可以大大减少DOM操作，从而降低渲染时间和内存占用，解决页面加载慢、卡顿等问题，改善用户体验。

最终在这里我们可能已经明确了浏览器扩展的一些非常Hack能力的实现，同时可能也会发现浏览器扩展的权限是真的非常高，在V2版本中甚至连HTTP Only的Cookie都可以拿到，在V3中限制就多了起来，但是整体的权限还是非常高的，所以在选择浏览器扩展时还是需要谨慎，要不就选择用户比较多的，要不就选择开源的。不过之前类似EDGE扩展的事件还是不容易避免，简单来说就是EDGE。

本文我们介绍总结了应该如何操作剪贴板，也就是我们在浏览器的复制粘贴行为，并且在此基础上聊到了在Canvas图形编辑器中的焦点问题以及如何实现复制粘贴行为，虽然暂时不涉及到Canvas本身，但是这都是作为编辑器本身的基础能力，也是通用的能力可以学习。针对于这个编辑器我们可以介绍的能力还有很多，整体来看会涉及到数据结构、History模块、复制粘贴模块、画布分层、事件管理、无限画布、按需绘制、性能优化、焦点控制、参考线、富文本、快捷键、层级控制、渲染顺序、事件模拟、PDF。

本文我们介绍总结了我们的图形编辑器中数据结构的设计以及History模块的实现，虽然暂时不涉及到Canvas本身，但是这都是作为编辑器本身的基础能力，也是通用的能力可以学习。后边我们可以介绍的能力还有很多，例如复制粘贴模块、画布分层、时间管理、无限画布、按需绘制、性能优化、焦点控制、参考线、富文本、快捷键、层级控制、渲染顺序、事件模拟、PDF排版等等，整体来说还是比较有意思的，欢迎关注我并留意后续的文章。

这次对于Canvas的体验让我感觉还是不错的，后边我也会写一些在实现的时候碰到的问题以及如何解决问题的文章，不过我目前的主业还是还是写富文本编辑器，富文本编辑器也是天坑中的一员，后边也可能会先写编辑器相关的文章。

当我们实现在线文档平台时，划词评论的功能是非常必要的，特别是在重文档管理流程的在线文档产品中，文档反馈是非常重要的一环，这样可以帮助文档维护者提高文档质量。而即使是单纯的将划词评论作为讨论区，也是非常有用的，尤其是在文档并不那么完善的情况下，对接产品系统的时候可以得到文档之外的输入。那么本文将通过引入协同算法来解决冲突，从而实现在线文档的划词评论能力。我们即将要聊的OT与CRDT。

当我们实现在线文档的系统时，通常需要考虑到文档的导出能力，特别是对于私有化部署的复杂ToB产品来说，文档的私有化版本交付能力就显得非常重要，此外成熟的在线文档系统还有很多复杂的场景，都需要我们提供文档导出的能力。那么本文就以Quill富文本编辑器引擎为基础，探讨文档导出为MarkDownWordPDF插件化设计实现。文章中我们即将要聊到的每个转换器设计都有相关示例，在实现DEMO的过程中也是踩了很多坑，给予的示例可以完成纯前端的数据转换，也可以通过Node来实现，还是比较有参考价值的。Markdown。

当我们实现在线文档的系统时，通常需要考虑到文档的版本控制与审核能力，并且这是这是整个文档管理流程中的重要环节，那么在这个环节中通常就需要文档的diff能力，这样我们就可以知道文档的变更情况，例如文档草稿与线上文档的差异、私有化版本A与版本B之间的差异等等，本文就以Quill富文本编辑器引擎为基础，探讨文档diff算法的实现。

webrtc是一项实时通讯技术，允许网络应用或者站点，在不借助中间媒介的情况下，建立浏览器之间点对点的连接，实现视频流、音频流、文件等等任意数据的传输，WebRTC包含的这些标准使用户在无需安装任何插件或者第三方的软件的情况下，可以创建点对点的数据分享和电话会议等。

在现代化前端开发中，我们可以借助构建工具来简化很多工作，单应用多端构建就是其中应用比较广泛的方案，webpack中提供了loader与plugin来给予开发者非常大的操作空间来操作构建过程，通过操作中间产物我们可以非常方便地实现多端构建，当然这是一种思想而不是深度绑定在webpack中的方法，我们也可以借助其他的构建工具来实现，比如rollupviterspack等等。

在前文中我们探讨了很多关于富文本引擎和协同的能力，在本文中我们更偏向具体的应用组件实现。在一些场景中比如组件库的文档编写时，我们希望能够有实时预览的能力，也就是用户可以在文档中直接编写代码，然后在页面中实时预览，这样可以让用户更加直观的了解组件的使用方式，这也是很多组件库文档中都会有的一个功能。那么我们在本文就侧重于React组件的实时预览，来探讨相关能力的实现。文中涉及的相关代码都在，在富文本文档中的实现效果可以参考。

在前文中我们探讨了很多关于富文本引擎和协同的能力，在本文中我们更偏向具体的应用组件实现。在一些场景中比如组件库的文档编写时，我们希望能够有实时预览的能力，也就是用户可以在文档中直接编写代码，然后在页面中实时预览，这样可以让用户更加直观的了解组件的使用方式，这也是很多组件库文档中都会有的一个功能。那么我们在本文就侧重于React组件的实时预览，来探讨相关能力的实现。文中涉及的相关代码都在，在富文本文档中的实现效果可以参考。

Chrome扩展是一种可以在Chrome浏览器中添加新功能和修改浏览器行为的软件程序，例如我们常用的AdGuard等等，这些拓展都是可以通过来修改、增强浏览器的能力，用来提供一些浏览器本体没有的功能，从而实现一些有趣的事情。

drawio是一款非常强大的开源在线的流程图编辑器，支持绘制各种形式的图表，提供了Web端与客户端支持，同时也支持多种资源类型的导出。

在前边初探富文本之CRDT协同算法一文中我们探讨了为什么需要协同、分布式的最终一致性理论、偏序集与半格的概念、为什么需要有偏序关系、如何通过数据结构避免冲突、分布式系统如何进行同步调度等等，这些属于完成协同所需要了解的基础知识，实际上当前有很多成熟的协同实现，例如automergeyjs等等，本文就是关注于以yjs为CRDT协同框架来实现协同的实例。

由于CRDT是处理分布式系统数据同步问题的通用解决方案，所以本文并没有局限于在富文本数据结构的设计，而是从分布式数据同步的角度来理解CRDT，并且穿插着CRDT在富文本领域上的应用，从而让我们能够更好地理解这个数据模型。同样，本文介绍的内容也只是冰山一角，分布式数据的同步一直以来都是个复杂的问题，回归到富文本领域上，如何保证多人协同的编辑器性能、在CAP理论下如何做取舍策略、如何保证数据的稳定性可恢复可回溯、光标的同步处理、如何处理Undo/Redo等等，都是需要深入研究并且设计的。

在前边初探富文本之OT协同算法一文中我们探讨了为什么需要协同、为什么仅有原子化的操作并不能实现协同、为什么要有操作变换、如何进行操作变换、什么时候能够应用操作、服务端如何进行协同调度等等，这些属于完成协同所需要了解的基础知识，实际上当前有很多成熟的协同实现，例如ot.jsShareDBot-jsonEasySync等等，本文就是以ShareDB为OT协同框架来实现协同的实例。

在上边的论述中我们似乎得到了一个不错的方案，但是实际上文中描述的内容也只是冰山一角，一个稳定协同过程还面临着诸多问题，例如需要支持多人协同的Undo/Redo，保证客户端与服务端OT算法的统一、在CAP理论下如何做取舍策略、如何保证多人协同的编辑器性能、如何保证数据的稳定性可恢复可回溯、光标的同步处理等等，当然不可能拥有从一开始就完美的架构设计，都是在发现问题之后一步步地让其变得完美。说了这么多，实际上目前已经有很多开源的OT。

富文本编辑器通常指的是可以对文字、图片等进行编辑的产品，具有所见即所得的能力。对于Input、Textarea之类标签，他们是支持内容编辑的，但并不支持带格式的文本或者是图片的插入等功能，所以对于这类的需求就需要富文本编辑器来实现。现在的富文本编辑器也已经不仅限于文字和图片，还包括视频、表格、代码块、思维导图、附件、公式、格式刷等等比较复杂的功能。