Herbert

不算是吧。。。因为我觉得 Vditor 的工程实在是太大了，而且敏捷度不够，有些东西是很难实现的。

MarkMax 通过 millionjs 提供了 VDOM 的特性，几乎实现了原生性能下的 markdown 渲染。体积远小于 Lute，重写了 markdown-it 的 renderer（这就导致了不支持 markdown-it 所有的插件）。不过还是蛮简单兼容了大部分 markdown-it 的插件，也可以兼容之前对于 Vditor 的插件设计，而且也提供了生命周期之类的特性 emmmm 当然也去解决 markdown-it 可能存在的 rules 冲突的问题，我感觉 docsify 等等的插件设计都存在这个问题

设计之初还是为了解决渲染的问题，后来给 million 的反馈比较多，成了 collaborator。后来我发现玩法还可以更多，因为可以直接生成 VNode Tree，MarkMax 又可以拥有 million 所有的特性，包括兼容 Vite、使用 million/react 等等，非常的有趣。

我有蛮多想法的，但是在准备研究生考试，所以未来一年都不打算更新代码了。PR Welcome~

我自己对 i18n 还比较有经验，也主要是做前端的。我的建议还是直接通过语法树翻译比较好，当然你也可以转化到 HTML 再翻译。相同点是基于编译原理来翻译，不要试图自己正则提取。

通过 markdown 的话，我建议用 marked.js 语法树比较简单，非常容易上手。如果你有 HTML 需求的话，可以转化 HTML 再翻译，用 million 这个项目来做 VDOM 结合 SPA 性能极高。

可以啊，我其实真的给开源贡献并没有几年。可以从简单的项目源码开始看，贡献实现自己的 idea 被合并了就足够了

🤣 不是大佬，就想把这个项目贡献的更开放一些。可能会有提很多性能优化 issues 建议，希望 V 姐不要看 GitHub 头大 2333（逃

看 Vue 的源码分析，又有了给 Vditor 嵌入 vdom 进行 diff 更新的想法，比较喜欢 sv 模式的我总感觉好像更新的时候有卡顿的情况

我感觉这是得看场景的，单纯做个编辑器来说确实不应该禁止，如果是通用的开源项目的话，提供这个可选项是个不错的 feature

之前 iframe 还有一个问题：不正确的 iframe src 输入会导致页面卡死甚至浏览器崩溃 · Issue #918 · Vanessa219/vditor (github.com)

issue 里面提到的方法，在前端可能可以一定程度山解决 src 导致的 XSS，直接禁掉 iframe 的键入比较好

@88250

哈哈哈，我提了这个 issue 支持渲染 React, Vue 组件 · Issue #1188 · Vanessa219/vditor (github.com) ，我现在在做 Vditor Plugin HerbertHe/vditor-plugin: Vditor plugin helper for Vditor Plugin Development! (github.com) 和重构类型定义。

如果往富文本发展的话，是需要支持拓展状态机的，复杂度会提升很多。这个项目我再看看，插件化特性增加其实会导致性能下降，这需要针对具体场景优化。

实际来说，现在没有让我觉得还不错的 markdown 编辑器。所见即所得和即时渲染多多少少有语法问题，而且还有卡顿的情况。总体来说，我更关注渲染器。。。编辑器 hold 不住，slate 还有中文的问题

如果基于标准 markdown 的语法的话，其实不存在 tokenizer 的问题。我认为 tokenzier 的优化支持，只是进一步通过 AST 提高渲染时的效率，比如我下面提的这个 issue：

支持 XML 解析为组件 · Issue #164 · 88250/lute (github.com)

在我 PR lute 的 RenderJSON 这个 API 之前，是无法通过 lute 实现前端全自定义渲染的。其实如果愿意的话，通过这个 API 可以完全前端自行实现渲染器 emmm。当时我只是为了解决 Vditor 还需要通过第三方库实现大纲渲染的问题，仔细研究的话还是蛮好玩的。

在 tokenizer 的问题上，lute 似乎在试图把这部分剥离重构，如果顺利的话通过 js 来自定义 token 的解析也不是问题。只是我觉得可能就偏离作为一个 markdown 解析器的初心了，这个发展方向就变成了富文本解析了。

Vditor 的合并比较慢，我设计了一套插件解耦，对于运行时的设计可能需要等待很长的时间。我开始慢慢有想法专门做一套 markdown 渲染器脱离 Vditor 了，但就目前自己的工作安排来说，优先级并没有那么高。markdown-it 的文档写的实在是太差了，之前有想法通过 markdown-it 直接支持小程序渲染 markdown。Vditor 如果重构渲染部分的话，是可以实现同步渲染的（加点逻辑就行了，部分特性可能不支持

其实目前的主要矛盾还是在 lute.min.js 实在是太大了（即使有 jsdelivr CDN 也还是慢），golang 似乎并没有官方支持 wasm 的打算。gopherjs 和 go-wasm 的作者是同一个人，go-wasm 的引入也并不优雅，打包了 go 的运行时。。。所以，我都有用 rust 重构 lute 的想法了（我随便说说的，别当真 233333

为啥不可以先获取数据呢？

之前我也试图把 lute 编译到 wasm 来着，其实 go wasm 和 gopherjs 的作者是一个人。go 似乎也并没有向 wasm 发展的意思。

在给 Vditor 开发自定义渲染器和 Lute PR renderJSON 这个方法的时候，我就发现了这个问题，这也是 renderJSON 这个方法为啥设置 Flag 这个特性的原因。对于起装饰性作用的块并不需要保留子节点内容，不然会造成导出语法树数据的冗余。

还有个问题是开发自定义渲染器，使用 API 获取数据的情况其实并不一致，这个给自定义渲染器提出了很大的挑战。

等着 PR 合并，我先做了代码风格规范和 Sass 迁移 Less。我预估了一下底层代码结构得大改（滚动更新），等着慢慢合并（V 说怕我动作大了跟不上 😂

我是希望在 Vditor 的项目上更新，因为没有打算做编辑器，只做渲染部分。

233333，先动手 Vditor，有时间再继续看看 Lute~Lute 现在也在寻求更新 emmm

该内容仅作者和楼主可见。

基于 Vditor 周围的生态项目我做了不少，碰到过很多“开发不舒服”的地方，因为各种原因先暂停了更新。如果 Vditor 能作为一个独立项目运营的话，我愿意把现有的所有项目全部捐献给社区。

之前 PR 里面的贡献是把 Sass 和 Lint 工具全部改掉了，先解决最基本的开发问题。核心 API Vditor.render() 和 Vditor.use() 实现再迭代大改底层加载逻辑。如果顺利的话，Vditor 的自身代码体积会减小很多，拓展性会增强很多，开源影响力也会更大~

大半夜不睡觉写代码属于是，哈哈哈哈哈~

你可以使用 renderJSON 这个 API 获得节点，或者用第三方 AST 生成工具

哈哈哈，还行

哈哈哈，尽自己所能

我自己基于 Vditor 手撸过几乎整套工具链，也贡献过代码。谈谈我碰到过的坑，Vditor 有些地方还是需要注意的。

• Vditor 是异步加载的，可能会导致 DOM 伸缩的问题，建议楼主隐藏长评论完整渲染
• Vditor 依赖的 lute.min.js 包很大，很可能会出现性能问题
• Vditor 全局样式需要统一，否则会出现样式污染的问题

这个自己封一层组件就好了，Vditor 定位于不同框架的编辑器，通过 React 的 useEffect 和 createRef 钩子就可以组件化实现

这个大纲是额外生成的，自己画就好了，我印象里 vditor 没有暴露 headings 的结构内容，可以用 marked.js 生成节点树自定义渲染

这两个方法的结果是不一样的，得看具体需求进行解决

Lute 里面有很多 vditor 文档里面没有表现的节点信息，具体可以参考 lute 源码里面的渲染器 https://github.com/88250/lute/blob/master/render/html_renderer.go#L33

Lute 的渲染逻辑是先分块级元素，再分行级元素，然后逐层嵌套进行渲染的。所有的文本内容到最后其实都是 renderText() 这个做的文本渲染，建议逐层自定义的方式进行实现。node.Text() 的属性是包含所有子节点的文本内容，并不能拿到链接。在给 Lute PR 的时候发现了这个问题，如果是列表的话，这个会拿到所有的子项源数据。node 并不完全是嵌套结构，标识符渲染、文本渲染其实是平级的。

感谢大佬的指点，根据 demo.js 和 Vditor 源码中的 types 尝试实现了节点的替换，但类型是字符串。对于产生组件来说，好像不是很合适，不知道 callback 的内容的类型是否可以修改。

如果可以的话，还带来了一个新的问题。

比如 renderStrong 这一族的自定义渲染器有五个

• renderStrong
• renderStrongA6kOpenMarker
• renderStrongA6kCloseMarker
• renderStrongU8eOpenMarker
• renderStrongU8eCloseMarker

其中的 renderStrong 渲染器自带了 DOM 节点 <strong></strong>，如果是字符串的话可以通过替换 xxxOpenMarker 和 xxxCloseMarker 的渲染来实现。但是如果支持返回组件的话，就会存在组件不闭合的报错，例如

// 返回值类型为string
renderStrongA6kOpenMarker: (node, entering) => {
    if(entering) {
        return ["<View>", Lute.WalkContinue]
    }
}

// 返回值为组件之后
renderStrongA6kOpenMarker: (node, entering) => {
    if(entering) {
        return [<View>, Lute.WalkContinue]
    }
}

// 返回值类型为string
renderStrongA6kCloseMarker: (node, entering) => {
    if(entering) {
        return ["</View>", Lute.WalkContinue]
    }
}

// 返回值为组件之后
renderStrongA6kCloseMarker: (node, entering) => {
    if(entering) {
        return [</View>, Lute.WalkContinue]
    }
}

如果可以通过对 renderStrong 的渲染器添加清空默认 DOM 的渲染，可以直接规避这个可能的 issue

renderStrong: (node, entering) => {
    if(entering) {
        return [<View>node.Text()</View>, Lute.WalkContinue]
    }
}

// 输出
// <View>node.Text()</View>

// 而非
// <View>node.Text()</View><strong>node.Text()</strong>

并且还可以直接支持 React、React Native 等生成自定义的组件 emmmm

options 的 value 参数设置初始值无效，在编辑器中无法初始化

谢谢，我找到问题在于 next 的 SSR 了，动态引入禁掉 SSR 问题就解决了