从文章渲染的混乱谈halo的插件主题开发规范

[holwell]

你当前使用的版本

lts2.x latest

描述一下此特性

最近想手搓个halo 主题，于是就开始看开源大佬们的主题代码以及一些官方插件，发现文章渲染这块很矛盾。

以 highlight.js 为例，它本应该是一个前端的渲染脚本，加上主题要使用 pjax 加载，需要掌握回调渲染的时机，这么看着它像属于主题的一部分吧。但是，又出了相应的官方插件，但插件引入的优势是在后端的前台 UC 支持编辑器预览，这么看着它做成插件引入也很合理。

再以 katex 为例，假如我使用的是 Markdown 格式而非官方的富文本方式写文章，用的 vditor 编辑器，那你可能会看到在 vditor 编辑器在前端渲染中引入了 katex.js，在官方 katex 插件里再引入 katex.js，在主题里又引入了 katex.js 这么多种可能。灯箱这类文章渲染的插件也是类似。
你能斩钉截铁的说哪个地方引入不合理吗，也不好说，编辑器开发者有自己依赖性的焦虑，主题作者也有自己的担忧，这种冲突和混乱肯定说明了一定的规范设计问题。

说了这么多，可能已经比较混乱了，那就回到一个具体的问题上：katex/highlightjs 这类文章渲染脚本该由插件引入？还是编辑器引入？还是主题引入？
本质上可能还是各个插件的职能太混乱，又动 UC 又动前台，我在动你也在动，很矛盾很混乱

附加信息

No response

[ruibaby]

说到底，就是前端实现混乱，谁都想实现，官方出的 KaTex、highlight.js 就是想统一实现，我们肯定是优先考虑默认编辑器，让其在编辑阶段和最终渲染阶段保持统一。你说到的 vditor 这种我们几乎无法干预，插件说明应该也有对应的适配提示。

说了这么多，可能已经比较混乱了，那就回到一个具体的问题上：katex/highlightjs 这类文章渲染脚本该由插件引入？还是编辑器引入？还是主题引入？本质上可能还是各个插件的职能太混乱，又动 UC 又动前台，我在动你也在动，很矛盾很混乱

你可以说出你的建议。

[holwell]

如果编辑器和主题开发者是同一个人，确实可以做到编辑阶段的预览和最终的前端渲染一致，也不用额外引入资源，这个思路是没问题的。但大多数情况下，编辑器的作者和主题开发者是不同的人，这时候可能就得把各自的职能划分清楚，具体说就是编辑器就做好编辑阶段的渲染，主题做好前端的最终渲染，互不干涉。但互不干涉也意味着编辑阶段和最终阶段的渲染不可能保持一致，其实也就论证了在这种情况下想让这两者统一的初衷可能一开始就是错误的。

当然，所有烦恼的出现都是因为我们想实现比其他博客更好的编辑体验的初衷，这些问题本不该是问题。

最后，我还有个比较奇怪的想法，就是把编辑阶段的渲染开放给主题开发者，对他们来说代价应该也不算大，无非就是引入他们对 post 页中 post.content.content 进行处理的一些 css/js，再规范一下 css 的容器类名和 js 渲染的接口，即方便开发也方便编辑器调用，具体的可行性和复杂性未知。

[ruibaby]

具体说就是编辑器就做好编辑阶段的渲染，主题做好前端的最终渲染，互不干涉

这样可能会更加混乱，从正常的使用流程来讲，用户很可能在编辑阶段可以正常渲染，但他并不知道为什么他的主题不支持。在 1.x 阶段我们就已经遇到了很多这样的问题，比如：编辑器支持代码高亮、数学公式、图表，但当前主题支持的不完整，可能使用了和编辑器不同的渲染库（代码高亮就有 highlight.js、prism.js，数学功能有 KaTex、MathJax 等），也可能完全不支持，这就会导致体验上的差异。

最后，我还有个比较奇怪的想法，就是把编辑阶段的渲染开放给主题开发者

如果你指的是让主题扩展默认编辑器，比如让主题扩展编辑器的代码高亮渲染。这确实是一个很好的想法，在未来的大版本迭代中可能会考虑，基本上有两种实现方式：

1. Halo 插件开发的 UI 部分可以由主题提供，毕竟插件的 UI 部分本身就是一个大的对象。
2. 主题依赖插件，主题开发者可以将和主题相关的插件功能直接内置到主题中，跟随主题的安装和更新进行加载。

[holwell]

大致归纳为两个部分，一个是把文章渲染这部分逻辑抽象出来，让编辑器和主题使用同一个渲染逻辑，另一个就是插件的强制依赖声明，无论是插件与插件间的，还是主题与插件间的，强制显示的声明需要依赖哪些插件。感觉这个工程改动比较大，还得靠你们将来仔细考量设计和实现，salute！