让我们一起完成WYSIWYG(所见即所得)的markdown编辑器

[[Lupoy]]

Lupoy

3,378 阅读7分钟

阳光正好，微风不燥。

前言

万事开头难，鬼知道在写这篇文章的时候我踌躇了多久。

在知乎上有一篇帖子在讨论Markdown编辑器做成WYSIWYG(所见即所得)形式有什么弊端。

本文相对而言，更像是开篇总结，实质内容没多少，活脱脱一篇菜鸡踩坑日记。

对于一个程序员来说，我们使用markdown大多是在README.md或者api文档中，样式是我们从不去关心的，因为市面上有很多优秀的markdown编辑器： mdnice 、 vditor 等等。

退而求其次，供我们选择的markdown解析渲染插件也有很多： marked 、 markdown-it 。

再退而求其次(内心OS:对，我就是这么没有底线)，vscode、webstrom、py、Go....甚至是文本编辑器，我们都可以去写markdown(至于样式，我都退成这样了，给个活路吧亲)。

言归正传，做一款左右预览的markdown编辑器不算难，从旁观者的角度来看，无非是选个框架，去npm哐哐哐哐install一些插件，接着左边儿跟我一起画个龙(编辑区);在你右边儿画一道彩虹(预览区),在你胸口上比划一个郭富城(菜单栏)，至于优化，再说再说。

在写这篇文章的前几个月，我基于React+monaco-editor+markdown-it做了一款左右预览的markdown编辑器，但是(敲黑板),无论多么完善他，总是会有左右滚动不同步的问题，无论使用codemirror还是monaco-editor，他们都是一款成熟的编辑器，但是(再敲黑板),我们在右侧预览的时候，当我们左侧插入图片，右侧将图片显示出来，它和左侧的图片语法不能够完美的对应上，例如：当我们左侧图片链接已经滚出可视区域，而右侧图片因为高度的原因，或多或少都会出现图片还没滚动出可视区域的问题。

为了解决它，我调研了很多成熟的编辑器，做得好的： stackedit vditor HyperMd balaala一大堆。

由此，引出了我长达几个月的踩坑之旅。(朱局长：他平时就这么勇的吗？🐶)

ContentEditable

那时，我们还年轻。总觉得世界应该是我们的

在使用 contenteditable="true" 的时候踩坑不仅是单行内容在结构嵌套的情况下光标位置的问题，这个问题的解决可以参考vditor的解决方案，动态向内容中插入 <wbr /> 标签，然后实时获取标签位置，将光标移动到这个标签之后删除这个标签。

但是相应也会产生一个问题，因为vditor是使用了自己编写的词法分析器---Luter，所以它不必担心这个 wbr 标签会对输出的html格式产生什么样的影响，但是，我们如果使用marked或者markdown-it去解析内容的时候，因为有这个标签的存在，可能会存在将加粗解析为两个斜体(因为中间有 wbr)

vditor

通过阅读vidtor的源码（对不起，vditor作者，🧎♀️），我知道了，他其实自定义了markdown的词法分析---Luter，在此基础之上完成了vidtor编辑器，我最开始想要尝试使用Luter引擎，但是后来困难战胜了我脆弱的小心灵，同时给我造成了不可磨灭的伤害，不是说Luter不好，相反，他脱离于正则去校验是否输入为markdown特殊语法，在响应速度上会优于很多词法分析器，但是他对我这个菜鸡而言，太难了，我曾经在他的基础上连续开发编辑器半个月左右，后来将这些代码全部放弃，重新去考虑其他的了，因为：

我觉得我再写也不会超越vditor（Jay：我感觉我一直活在“夏洛”的影子里）因为单从编辑器这个角度而言，至少是我阅过的源码中顶优秀的存在，像国外的stackflowd 的优秀开源工具stackedit，他的缺点在于使用了vue作为了技术框架，此举不是为了批判vue，因为我也使用vue使用了几年，而vditor是脱离于三大框架之外，更能一套代码多端适配。这才是我推荐的原因，当然，也得说说vditor的左右同步滚动做的不到位呀，还是很不同步的
我再怎么写，也是vditor mini，因为luter和vditor人一家产的，在使用luter的时候或多或少还是会使用到vditor的东西，那和直接对vditor的源码进行删减有甚区别？
我是个菜鸡而已，单单一个heading的语法就让我够头疼了，在光标切换到其它行的时候，我们之前行的内容如何展示，我拿到的是text，并不是一个stream流，这让我很头疼，我总不能走一个for循环去解决这个吧