写在后面的

曾经记不清什么时候开始接触的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嗷~哈哈哈哈