From 5622a5926b5c029c00c4515cf839a227514f76e0 Mon Sep 17 00:00:00 2001 From: WindRunnerMax <651525974@qq.com> Date: Sun, 12 Jan 2025 10:27:56 +0800 Subject: [PATCH] 25/01/12 --- ...54\347\274\226\350\276\221\345\231\250.md" | 45 ++++++++++++++----- README.md | 2 +- Timeline.md | 2 +- 3 files changed, 37 insertions(+), 12 deletions(-) diff --git "a/Backup/\344\273\216\351\233\266\350\256\276\350\256\241\345\256\236\347\216\260\345\257\214\346\226\207\346\234\254\347\274\226\350\276\221\345\231\250.md" "b/Backup/\344\273\216\351\233\266\350\256\276\350\256\241\345\256\236\347\216\260\345\257\214\346\226\207\346\234\254\347\274\226\350\276\221\345\231\250.md" index 8a3275c..bc8bf1d 100644 --- "a/Backup/\344\273\216\351\233\266\350\256\276\350\256\241\345\256\236\347\216\260\345\257\214\346\226\207\346\234\254\347\274\226\350\276\221\345\231\250.md" +++ "b/Backup/\344\273\216\351\233\266\350\256\276\350\256\241\345\256\236\347\216\260\345\257\214\346\226\207\346\234\254\347\274\226\350\276\221\345\231\250.md" @@ -1,38 +1,63 @@ # 从零设计实现富文本编辑器 -富文本编辑器是允许用户在输入和编辑文本内容时，可以应用不同的格式、样式等功能，例如图文混排等，具有所见即所得的能力。与简单的纯文本编辑组件``等不同，富文本编辑器提供了更多的功能和灵活性，让用户可以创建更丰富和结构化的内容。现代的富文本编辑器也已经不仅限于文字和图片，还包括视频、表格、代码块、思维导图、附件、公式、格式刷等等比较复杂的功能。 +富文本编辑器是允许用户在输入和编辑文本内容时，可以应用不同的格式、样式等功能，例如图文混排等，具有所见即所得的能力。与简单的纯文本编辑组件``等不同，富文本编辑器提供了更多的功能和灵活性，让用户可以创建更丰富和结构化的内容。现代的富文本编辑器也已经不仅限于文字和图片，还包括视频、表格、代码块、附件、公式等等比较复杂的模块。 - 开源地址: - 项目笔记: ## Why? -那么为什么要从零设计实现新的富文本编辑器，因为当前已经有很多优秀的编辑器实现。例如极具表现力的数据结构设计`Quill`、结合`React`视图层的`Draft`、纯粹的编辑器引擎`Slate`、高度模块化的`PromiseMirror`、开箱即用的`TinyMCE/TipTap`、集成协同解决方案的`EtherPad`等等。 +那么为什么要从零设计实现新的富文本编辑器，编辑器是公认的天坑，且当前已经有很多优秀的编辑器实现。例如极具表现力的数据结构设计`Quill`、结合`React`视图层的`Draft`、纯粹的编辑器引擎`Slate`、高度模块化的`PromiseMirror`、开箱即用的`TinyMCE/TipTap`、集成协同解决方案的`EtherPad`等等。 -而我前段时间都在专注于编辑器的应用层实现，在具体实现的过程中也遇到了很多问题，并且记录了相关文章。然而在应用层实现的过程中，遇到了很多我个人觉得可以优化的地方，特别是在数据结构层面上，希望能够将我的一些想法应用出来。举例来说，主要有下面的几个原因: +我也算是比较关注于各类富文本编辑器的实现，包括在各个站点上的编辑器实现文章我也会看。但是我发现这其中极少有讲富文本编辑器的底层设计，绝大多数都是将的应用层，例如如何使用编辑器引擎实现某某功能等。这些应用层的实现本身也会有一定复杂性，但是底层的设计却是更值得探讨的问题。 -## 编辑器专栏 +而我恰好前段时间都在专注于编辑器的应用层实现，在具体实现的过程中也遇到了很多问题，并且记录了相关文章。然而在应用层实现的过程中，遇到了很多我个人觉得可以优化的地方，特别是在数据结构层面上，希望能够将我的一些想法应用出来。具体来说，主要有下面的几个原因: -从小白开始记录的文章，记录的内容很多，基本上是想到什么就写什么，毕竟是作为平时学习的记录。然后在`24`年写了比较多的富文本编辑器的文章，主要是整理了平时遇到的问题以及解决方案，集中在应用层的设计上，例如: +## 编辑器专栏 +我的博客是从`20`年开始写的，记录的内容很多，基本上是想到什么就写什么，毕竟是作为平时学习的记录。然后在`24`年写了比较多的富文本编辑器的文章，主要是整理了平时遇到的问题以及解决方案，集中在应用层的设计上，例如: - [初探富文本之文档虚拟滚动](https://github.com/WindRunnerMax/EveryDay/blob/master/RichText/初探富文本之文档虚拟滚动.md) - [初探富文本之OT协同算法](https://github.com/WindRunnerMax/EveryDay/blob/master/RichText/初探富文本之OT协同算法.md) -- ... +- [...](https://github.com/WindRunnerMax/EveryDay#richtext) -此外，这段时间还研究了`slate`富文本编辑器相关的实现，并且也给`slate`的仓库提过一些`PR`。还写了一些`slate`相关的文章，同样也是比较关注于应用层的实现，例如: +此外，前段时间还研究了`slate`富文本编辑器相关的实现，并且也给`slate`的仓库提过一些`PR`。还写了一些`slate`相关的文章，并且还基于`slate`实现了一个文档编辑器，同样也是比较关注于应用层的实现，例如: - [WrapNode数据结构与操作变换](https://github.com/WindRunnerMax/EveryDay/blob/master/RichText/WrapNode数据结构与操作变换.md) - [Node节点与Path路径映射](https://github.com/WindRunnerMax/EveryDay/blob/master/RichText/Node节点与Path路径映射.md) -- ... +- [...](https://github.com/WindRunnerMax/EveryDay#richtext) + +在实现了诸多的应用层的功能之后，发现整个编辑器有很多可以深入研究的地方。特别是有些实现看似很理所当然，但是仔细研究起来会发现这其中有很多细节可以探究，例如在`DOM`结构后常见的零宽字符、`Mention`节点的渲染等等，这些内容都可以单独拿出来记录文章，这其实就是我想从零实现编辑器的最重要原因。 +`24`年开始写了很多业务上的东西，到了`25`年就略感题穷，而目前我也没有别的擅长的方面，由此写编辑器相关的内容是比较好的选择，这样对于文章的选题也会简单些。不过，虽然想的是深入写编辑器相关的内容，但是在平时遇到问题的时候，还是会记录下来，例如最近有个基于`immer`配合`OT-JSON`实现的状态管理的想法可以实现。 + +而对于编辑器的具体实现，我目前的目标是实现可用的编辑器，而不是兼容性非常好且功能完备的编辑器。主要是现在已经有非常多优秀的编辑器实现，且有很多生态插件可以支持，能够满足大部分的需求。目前我想实现的编辑器主要是兼容`Chrome`浏览器即可，移动端的问题暂时不会考虑。不过，如果能够将编辑器做得比较好的话，自然可以去做兼容性适配。 + +不过目前还是试探性地来设计并实现编辑器，期间必然会遇到很多问题，这些问题也将会成为专栏的主体内容。如果将来真的能够将编辑器适用于生产环境，那么这些文章就能够溯源到模块为什么这么设计，想必也是极好的。整体来说，我们不能一口吃成胖子，但是一口一口吃却是可以的。 ### 深入编辑器 +这部分是让我想起来一句话：我们富文本编辑器是这样的，你不写你不懂。 + +编辑器是个非常注重细节的工程，很多时候都需要深入研究浏览器的`API`，例如`document`上的`caretPositionFromPoint`方法，用以获取当前某个点所在的选区位置，通常用于拖拽文本后的落点定位。除此之外，还有很多选区相关的`API`，例如`Selection`、`Range`等等，这些都是编辑器实现的基础。 -零宽字符 +那么深入编辑器底层就是很有意义的事情，很多时候我们都需要跟浏览器打交道，即使是对我们平时的业务开发也会有价值。在这里我想聊一下编辑器中的零宽字符，以此例学习编辑器的细节设计，这是一个非常有意思的话题，类似这种内容就是不研究则不会关注到的有趣事情。 -选区末尾 +如果我们在开发者工具检查元素时，可能会发现一些类似于`​`的字符，这就是常见的零宽字符。例如在飞书文档的编辑器中，我们通过`$("[data-enter]")`就可以检查到其中存在的零宽字符。 + +```html + +\u200B +​ +``` + +那么从名字上来看，这个零宽字符在视觉上是不显示的，因为其是零宽度。但是在编辑器中，这个字符却是很重要的。简单来说，我们需要这个字符来放置光标，以及做额外的显示效果。需要注意的是我们在这里指的是`ContentEditable`实现的编辑器，如果是自绘光标的编辑器则不一定需要这部分设计。 + +我们先来聊一下额外的显示效果， + +选区末尾、撑起行内容 块级结构选择效果 +inline-block + ### 数据结构设计 数据结构设计 slate数据设计尽可能倾向于`HTML`的设计， diff --git a/README.md b/README.md index d15c95c..bd749b1 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ 如果觉得还不错，点个`star`吧 😁 -版本库中共有`492`篇文章，总计`92533`行，`1089603`字，`3037352`字符。 +版本库中共有`492`篇文章，总计`92585`行，`1091056`字，`3039950`字符。 这是一个前端小白的学习历程，如果只学习而不记录点什么那基本就等于白学了。这个版本库的名字`EveryDay`就是希望激励我能够每天学习，下面的文章就是从`2020.02.25`开始积累的文章，都是参考众多文章归纳整理学习而写的，文章包括了`HTML`基础、`CSS`基础、`JavaScript`基础与拓展、`Browser`浏览器相关、`Vue`使用与分析、`React`使用与分析、`Plugin`插件相关、`RichText`富文本、`Patterns`设计模式、`Linux`命令、`LeetCode`题解等类别，内容都是比较基础的，毕竟我也还是个小。此外基本上每个示例都是本着能够即时运行为目标的，新建一个`HTML`文件复制之后即可在浏览器运行或者直接可以在`console`中运行。 diff --git a/Timeline.md b/Timeline.md index b13afdc..a7bd414 100644 --- a/Timeline.md +++ b/Timeline.md @@ -1,6 +1,6 @@ # Timeline -前端笔记系列共有 423 篇文章，总计 75313 行， 862448 字， 2391090 字符。 +前端笔记系列共有 423 篇文章，总计 75313 行， 862445 字， 2391086 字符。 ### 2025-01-11 第 423 题：[Node节点与Path路径映射](RichText/Node节点与Path路径映射.md)