关于前端:markdown-自定义的思考

写在后面的

曾经记不清什么时候开始接触的 markdown 了，如同是从我的一个学长做了咱们学校的大数据协会论坛开始的。如果我没记错的话用的还是 b3log 的开源我的项目，应该是应用的 Symphony。起初听学长说太简单了，保护无从下手而后删库跑路了????

也正是他画的这个饼，让我从零开始设计一个社区给不同学科、不同业余的同学来应用，之前实现过的版本并不是很称心（应该在我的链滴帖子里还能找到），而后又开始了重构之路。也正是一直的与 markdown 不同的编辑器接触，也让我对 marked.js、markdown-it、for-editor、lute、vditor 等等的编辑器、编译器、渲染器有了很多的接触，对于 markdown 及其拓展语法有了各种奇奇怪怪的想法

for-editor-herb

for-editor 是一个 UI 设计十分不错的编辑器，它的底层解析引擎为 marked.js。marked.js 对于 markdown 的解析渲染在前端十分有名，并且在很多的编辑器下面也失去了利用。for-editor 很轻、很小、很美，然而也防止不了呈现了不少的 bug，也不反对很多的 features。过后只算是个开源我的项目的萌新，给作者提 PR 没有失去回复，而后给作者发邮件还是没有回复 23333 我显著感觉到作者如同无心再持续保护上来了，在 issues 外面也帮忙了一些老哥解决了一些问题。

直到有个老哥倡议我不如去本人新开一个仓库，而后本人来打包公布 2333 其实吧，过后做前端顶多算个页面仔，也就是本人写写页面这个样子，压根也没接触过 npm 的库咋公布，而后就试错硬着头皮来呗。修复了很多的 bug，一度狐疑人生???? 尤其是那个编辑器 - 几乎是噩梦，有趣味的同学能够理解一下前端如何实现一个富文本编辑器???? 我过后一度狐疑我是不是在试图写一个 word！！在编辑器开发里其实说问题吧，多也不多，也就是怎么撑开 textarea、怎么管制焦点、怎么获取选区这点问题???? 当然这只是开个玩笑，实操起来真的是狐疑人生。

for-editor 计算行号就显著有个问题，它的行号是基于 \n 来计算的，这基本是不精确的。在关上和敞开渲染的时候因为 textarea 的宽度会产生扭转。这就间接会导致，其实字它会换行，其实这跟行号就齐全不匹配了。起初我的改良计划是获取容器的理论高度，而后依据字高来算理论的行数。个别默认的字体大小 font-size: 16px;，而后明面上解决了这个问题，然而还是没能解决开关渲染导致的不精确，因为基本不会触发 height 产生扭转。。。这个很大水平上跟设计机制有关系（轻易看一看 HTML 就晓得问题了），不过整体体验影响还能够，尽管一度让我想重构整个编辑器。愚认为 vscode 的体验真的是神仙，vscode 其实晓得的都晓得是基于 electron 开发的，叹为观止。。。

下面就是举个例子，在 for-editor 外面也就实现了上面的一些性能，如同有老哥还把这个用于我的项目了????

• 更多的工具栏按钮
• 反对数学公式的渲染
• 反对响应式布局
• 反对纲要跳转锚点
• 反对纲要间接生成插入
• 内置简繁体中文、英文和日文的反对
• 反对自定义反对编辑器国际化
• 反对 GitHub Diff 语法渲染（这个 vditor 如同并没有齐全反对）
• 反对自定义注册代码高亮的语言类型
• 反对 emoji 短码渲染绘文字 emoji
• 反对 ==markdown== 语法行内高亮

其实我之前还筹备反对 mermaid 的，然而之前我始终没有解决渲染的问题，没找到渲染的机会，起初放弃反对了。到起初我其实比拟抗拒保护这个我的项目了，因为我能显著感觉到渲染越来越慢。在这个我的项目的 issue 里，也有老哥给我安利过 vditor，然而他貌似不会在 React 外面用 emmm。这个我的项目我简直调整了 80% 的代码构造，有一些问题不是很好修复，只能寄希望于重构???? 然而过后又在同步写着 pyvm，没有想法持续重构上来。起初业务代码越来越多就没有持续了，被我 Achieved 了，有 4 个 fork，应该还有老哥还在保护，我的项目能够在 for-editor-herb 体验。

在这个我的项目的开发中，我为了实现一些解析语法去浏览了 marked.js 的源码。marked.js 整个我的项目的灵魂在于正则表达式，外面的正则表达式写的十分十分厉害。在局部 features 实现的时候也参考了，marked.js 始终到高级应用局部都十分十分相熟。然而，性能和保护永远是最大的问题。

lute

先写 lute 的起因是 vditor 我始终在一直地关注着，并且始终发现问题和提 feature 疯狂“作妖”???? 心愿 @Vanessa V 姐不会感觉我超级烦????

接触 lute 的起因是有一些 feature 依附 vditor 没方法实现。举个例子，在 React Native 中如何实现 markdown 渲染？难道是套一个 WebView 加载 H5？尽管在某些场景不得不去这么实现，比方依赖 KaTeX 做数学公式渲染、abcjs 做五线谱渲染，要不就本人再写一个库？emmm WebView 会有很多的限度，而且其实在挪动端做 markdown 即时渲染的体验不会很好。即便是 GitHub 官网的 APP 也没有实现，而后我的眼光就放到了 lute 的身上 23333

lute 是基于编译原理应用 go 开发的，刚好一不小心之前自学过 golang，而后开始钻研 lute。看的很通俗，并没有关注生成 AST 的局部，本人关注的次要是在渲染的解决上。lute 对于外部实现方面没有文档，只能本人去看源码。lute 的代码结构设计很优良，很容易上手去浏览定位具体的问题和实现的地位。

剖析需要和具体实现：基于 lute 间接实现组件渲染其实是不理论的，即便起初 vditor 反对了自定义渲染器，然而其实依然是 string 类型的。而 React Native 的组件是 JSX，所以我须要一棵树，本人依据这棵树来遍历递归渲染。很遗憾，lute 其实并没有提供这个办法，lute 并不是一个纯正的解析器，而是同时是一个渲染器，间接生成了 DOM！如果你尝试在 js 外面调用 lute 裸露的某些在 godoc 有的办法，会间接报错。

其实，lute 的节点细分比 vditor 多很多，如同是有一百四十多个。并且随着个性的一直减少，这个数量还在减少。最初还是实现了“这棵树”的输入，自 lute v1.7.1 之后反对，是 lute.RenderJSON() 这个办法。这棵树实现了 vditor 绝大多数反对的语法输入，但其实 vditor 有很多很多的渲染都是在前端实现的。其实依附这个办法，是能够自行实现与 vditor 兼容的一个纯正的渲染器，能够自行看 lute 的文档 如何应用

当我开始基于 lute 写 npm 包的时候，发现了一个很重大的问题。lute 的包太大了，打包失败。lute 是通过 gopherjs 打包成 js 的，没方法拆包。上文提到 lute 其实并不是一个纯正的解析器，蕴含了渲染的局部，不晓得 @88250 D 哥有没有打算把解析的局部独自拆散进来，新成立一个极高效率的 markdown 解析器的我的项目 emmm

如果你想要应用 lute 自定义渲染器，或者写个库什么的，这并不影响你在 web 端的应用。能够参考 rollup 内部依赖的这部分，通过 CDN 内部引入问题不大的，只是把 lute 打包会呈现问题而已。

vditor

刚刚查了一下，在 vditor 总共提过 9 个 issues，开始提的问题是极蠢的，对 8 起，节约 V 姐的工夫了。不过如同我提的好几个 issue 起初的版本实现了 2333。比方这个 应用 hint at 办法报错，我心愿通过拓展 @ 这个办法，实现 at 的并不只是一个用户，甚至是能够援用一篇文章等。

不过有一说一，我回顾了一下我的 issue 还是感觉有一些是真的 low????vditor 的源码看了一部分，有的局部还是很有意思的，我也晓得了 vditor 为什么有的办法那么实现。vditor 的 features 更新速度总是比文档快很多，如果想尝鲜之类的话，倡议去浏览源码（手动滑稽）

不过，这几天发现 vditor 有一个问题我还是感觉挺重大的。当 vditor 和 SSR 一起应用的时候，可能会导致页面解体，甚至是浏览器解体。当你在 sv 模式下输出 iframe 这个 HTML 标签，可能会导致一些问题。具体探讨能够看这个 issue #918，需要是在这个 issue #906 提出的。

须要揭示把 vditor 当作编辑器的我的项目，markdown 原生反对 HTML 标签，所以除了开启 vditor 的平安过滤躲避 XSS 攻打（默认关上的）之外，还须要过滤 iframe 这个标签！如果是论坛等交互式网站的话，可能无法控制用户通过 iframe 植入广告甚至是非法网站！

iframe 渲染这个需要，其实实现起来并不简略，须要尤其留神过滤 iframe 的 domain 和缩小 iframe 导致的 GET 申请，有的援用网站不排除有拜访的风控。在下面 issue 的探讨里我提供了两种思路，目标就是为了 iframe 的申请和过滤非法域名，我曾经自行实现了第一种思路，依赖上面介绍的库实现起来其实非常简单。其实就是延时渲染或者防抖，这些其实在前端优化外面都有理论的利用，每个人都有不同的实现形式，不赘述了。

codeblock-iframe 语法

这是我在下面的思考中提出的一种语法，兴许之前可能有人提也能不肯定的。办法特地简略，即把 iframe 当作代码块解决，遵循 TOML 的语法，这样对代码侵入很小。

基于这个思维，我写了两个库别离反对了 webpack 等打包工具的调用和 web 端间接通过 script 进行援用，并且为 docsify 写了插件反对这种语法。

转化过程能够在这个 demo 里体验 demo

docsify 的应用在这个 demo 里体验 demo

仓库地址如下

• toml2iframe 反对 webpack 等打包工具
• codeblock-iframe 反对 web 端通过 CDN 导入
• docsify-codeblock-iframe 为 docsify 提供的反对插件

Todos

在我的脑子里，还有很多很多的 feature 提供给 markdown 进行反对，比方最近对 markdown 反对化学结构式很感兴趣。看了现存的极少的实现计划，感觉不怎么样，可能的话只能本人去钻研了，比方 zrender

因为本人是物理系的，对公式输出很敏感所以早都基于 KaTeX 尝试实现了 Tex

更多的想法的话，可能会为飞书写利用或者独自开发一个 PC 端为协同办公提供服务。尽管飞书的云文档很好用，然而还是防止不了它还是不能撑持很多的协同文档问题。所以，为团队的我的项目开发的话，可能会基于 vditor 实现一个协同文档的服务，有想法是借鉴 slack 实现。指标跟思源笔记的方向齐全不一样，次要协同文档、文档平安、权限管制等，实现起来的架构设计和算法还是挺难的。

因为 idea 太多了，导致本人写代码的速度跟不上哈哈哈哈哈

我的其余开源我的项目

就写我认为好用的吧，其余的小插件都在我的仓库里很好找的

• nbc 全称 nuco-backend-cli 是我针对限度团队 commit 格调和开发有的罕用需要写的命令行工具，基于 golang 开发，反对 MacOS、Linux 和 Windows 三端，曾经投入平时的开发之中应用了，并且提供了具体的文档应用文档
• nuco-docsify 这是为了团队我的项目生成文档模板的工具，反对很多 feature。这样咱们就不必要每一次都配置文档了，nbc 也提供了 nbc docs 间接生成文档，并且能够通过 nbc serve 间接启动动态预览！

还有一些文档翻译什么的，如果你感觉好用的话给个 Star 嗷~ 哈哈哈哈