如何让Waline服务端返回原始评论数据

[asforest]

目前正在做自己的Waline客户端，但是遇到一个很头疼的问题： 在拿到服务端返回的评论数据以后，我想自己渲染成Markdown，而不是作为xml直接插到dom中。 问题在于：返回的数据并不是评论时上传的原始数据，而是一个XML文本

如果是回复的另一条评论还会在开头附加一个@xxxx，我不得不用jq或者cheerio进行过滤过一次，很是不方便 请问目前有现成的配置选项能让comment字段直接返回上传时的数据吗（没有@xxx和

标签）

[lizheming]

目前没有办法，Waline 因为要和 Valine 数据结构保持一致，所以和 Valine 一样只存了转换后的内容。

[asforest]

目前没有办法，Waline 因为要和 Valine 数据结构保持一致，所以和 Valine 一样只存了转换后的内容。

是这样啊，我再想想其它办法吧，不管怎么说，还是谢谢回复啦

[lizheming]

你如果只是想要得到 Markdown 的话可以考虑用一些 html2markdown 之类的库处理一下也是可以的。

[asforest]

目前没有办法，Waline 因为要和 Valine 数据结构保持一致，所以和 Valine 一样只存了转换后的内容。

顺便再问一下，或者提个建议，以后会把兼容Valine做成独立的配置项目吗？ 我觉得很多地方都有改进空间 比如：时间返回的不是unix时间戳，需要用moment重新解析一次 还有子评论中会把第三层评论放到第二层里（虽然pid和rid的链接关系不会变）

（个人觉得是受Valine包袱的影响，需要兼顾Valine用户的习惯）

[asforest]

你如果只是想要得到 Markdown 的话可以考虑用一些 html2markdown 之类的库处理一下也是可以的。

嗯，Markdown渲染是完全没问题的，只是需要单独删减掉@xxx这个字符串而已，其实影响也不大的

[lizheming]

目前没有办法，Waline 因为要和 Valine 数据结构保持一致，所以和 Valine 一样只存了转换后的内容。

顺便再问一下，或者提个建议，以后会把_兼容Valine_做成独立的配置项目吗？ 我觉得很多地方都有改进空间 比如：时间返回的不是unix时间戳，需要用moment重新解析一次 还有子评论中会把第三层评论放到第二层里（虽然pid和rid的链接关系不会变）

（个人觉得是受Valine包袱的影响，需要兼顾Valine用户的习惯）

的确现在有一些 Valine 迁移过来的历史包袱。不过 Waline 侧可能已经不太好修改了，后续可以增加一个 raw_comment 原文字段存储用来解决你的 markdown 的问题。 时间这块主要是懒了，数据库原文输出的大部分场景能直接用就没管了。这个可能后续没有动力修改了，如果你有兴趣的话可以提 PR 修改下这个。 子评论的展示我认为是一种选择吧，可以用递归嵌套的方式，也可以用 Valine 的这种至多两层的形式。除了遵从 Valine 的规则来之外，其实两层展现的形式对数据输出也会更简单一点，另外在评论多的情况下现有的这种形式的展现样式要比递归嵌套会好看一点。如果你在自己实现客户端的话，倒是可以前端拿到了子评论的数据后再处理转换一下也是可以的。

Waline 保证 Valine 的兼容可能会作为固定的 feature 一直保存着，我觉得后续可以考虑采用现有的架构，更合理的数据结构新开发一个评论系统出来。

[asforest]

目前没有办法，Waline 因为要和 Valine 数据结构保持一致，所以和 Valine 一样只存了转换后的内容。

顺便再问一下，或者提个建议，以后会把_兼容Valine_做成独立的配置项目吗？ 我觉得很多地方都有改进空间 比如：时间返回的不是unix时间戳，需要用moment重新解析一次 还有子评论中会把第三层评论放到第二层里（虽然pid和rid的链接关系不会变） （个人觉得是受Valine包袱的影响，需要兼顾Valine用户的习惯）

的确现在有一些 Valine 迁移过来的历史包袱。不过 Waline 侧可能已经不太好修改了，后续可以增加一个 raw_comment 原文字段存储用来解决你的 markdown 的问题。 时间这块主要是懒了，数据库原文输出的大部分场景能直接用就没管了。这个可能后续没有动力修改了，如果你有兴趣的话可以提 PR 修改下这个。 子评论的展示我认为是一种选择吧，可以用递归嵌套的方式，也可以用 Valine 的这种至多两层的形式。除了遵从 Valine 的规则来之外，其实两层展现的形式对数据输出也会更简单一点，另外在评论多的情况下现有的这种形式的展现样式要比递归嵌套会好看一点。如果你在自己实现客户端的话，倒是可以前端拿到了子评论的数据后再处理转换一下也是可以的。

Waline 保证 Valine 的兼容可能会作为固定的 feature 一直保存着，我觉得后续可以考虑采用现有的架构，更合理的数据结构新开发一个评论系统出来。

时间和原始评论倒也影响不大，在前端简单处理一下就好了，保持现状也是个不错的选择

子评论的嵌套方式使用两层形成也许更“开箱即用”一点，适合大多数场景，只是如果有第三个人参与到回复中时结构就不那么清晰了(主要是我懒，想看看有没有现成的方案 :joy: )，不过我用代码简单处理一下也是没问题的

最后感谢回复，我还在研究Waline的源码，如果可能，我就提PR加个raw_comment配置项吧

[lizheming]

好的，真是太感谢了。在前端和服务端增加一下，sql 类的需要初始化一下该字段即可。

[asforest]

好的，感谢告知！