如何实现一个楼中楼的评论系统

蚊子前端博客
发布于 2017-09-01 01:19
多说,网易云跟帖等第三方评论系统无法长期维护更新,蚊子就自己实现一个楼中楼的评论系统

1. 实现前的思考

在经历过多说和网易云跟帖后,总算是下定决心自己要写一个评论系统了。

我们在使用的很多评论系统中,目前比较流行的就是楼中楼的方式了,比如百度贴吧,wordpress 等等。在这以前,一般都是按照时间顺序进行 1 楼、2 楼、3 楼的展示,如果要回复某个人,使用@符号标识出这个用户的名字,然后回复内容。可是这样存在一个很大的问题,讨论问题没有集中在一起,其他用户根本不知道你们在讨论什么,原作者在 1 楼发表评论,你进来回复这个用户的评论时,已经到 10 楼了,原作者再回复你又到 20 楼了。其他用户看到 10 楼时,早已经忘记原作者说了什么了。

如何实现一个楼中楼的评论系统-蚊子的前端博客

百度贴吧在改版之前就是这种方式,后来在新版中启用了楼中楼的方式,这种方式,关于某个话题的讨论就能集中在一块了。

如何实现一个楼中楼的评论系统-蚊子的前端博客

同时,知乎也对他的评论系统进行了一次改版,不过不是改版成楼中楼,而是在每个有对话评论的后面加上一个弹窗链接查看对话,点击链接后弹窗能看到这两个人之间互动的所有评论。

采用时间顺序倒序或者正序平铺的方式展示评论,这种方式实现起来简单,但是阅读困难;采用楼中楼的方式展示评论,对用户的阅读习惯比较友好,但是实现起来可能比较困难。不过,最后仍然决定采用楼中楼的方式来,虽然本人博客的评论量也少的可怜,不过还是决定要实现一下。

2. 数据表的设计

先说下前后端使用的语言和框架,前端考虑到页面渲染和比较多的事件调用,使用了 vue 框架,vue 应该说不是最好的选择,毕竟对一个评论的前端部门来说,可能有点大材小用,不过为了快速开发,也就选择了 vue。后端使用的是 php 语言,数据库使用的是 mysql。

数据库表的设计,既要考虑到可以导入以前的数据,又能方便以后添加新的评论。这里我创建了 3 个表: 文章表,用户表,评论表。

在网易云跟帖关闭之前,我把自己的数据导出来了(多说的数据已经丢失,不知道导出的格式是什么了),我们来看下网易云跟帖里导出数据的格式:

COPYJSON

{ "title": "从0到1学习node(七)之express搭建简易论坛", "url": "www.xiabingbao.com/node/2017/02/20/node-express-forum.html", "sourceId": "", "ctime": 1487581007000, "comments": [ { "cid": "72813956", "ctime": 1493107384000, "content": "这个论坛对node 的版本有要求吗 我的node比较老 下载你的源码 访问出错", "pid": "0", "ip": "xxx", "port": 0, "sc": "web", "vote": 0, "against": 0, "anonymous": false, "user": { "userId": "1074123", "nickname": "有态度网友06q23q", "avatar": "", "anonymous": false } }, { "cid": "77196403", "ctime": 1493714822000, "content": "不太清楚,我这里node版本是6.9.4,npm版本是3.10.10,你试一下升级node版本", "pid": "72813956", "ip": "xxx", "port": 0, "sc": "web", "vote": 0, "against": 0, "anonymous": false, "user": { "userId": "2414123", "nickname": "小小dd蚊子", "avatar": "http://cms-bucket.nosdn.127.net/1d6faddedb544cee93ff426a4aa2fe7620170322162349.jpg", "anonymous": false } } ] }

从上面的数据里,可以看到,每个文章都有标题,url 和评论,评论的每一项都有自己对应的 id,其回复的评论 pid,内容 content,该评论的用户 userid, nickname 和 avatar。我这里也就只摘取主要的信息录入到数据库中。

2.1 用户表

用户表相对来说比较简单,要考虑的就是原有的 userid 也要作为字段进行保存,方便在导入评论数据时能找到对应的用户,在评论数据也导入完成后即可将该字段删除,以后新添加的注册用户用不到这个字段了。用户表的设计:

字段类型说明
idint自增,主键
widint用户原有的 userid
nicknamevarchar(50)昵称
avatarvarchar(100)头像
statusint状态

设计好用户表后,将原数据中所有的用户都单独拿出来,然后使用 userid 作为 key 存储到一个数组中,这样也能起到一个去重的效果。把拿到的所有的用户数据存储到用户表

2.2 评论表

在设计评论表,主要考虑如下的因素:

  1. 评论必须依托于文章和用户才能存在,因此评论的外键是文章标识和 userid,留言板是一个文章内容为空的评论形式;

  2. 我想以后新的评论能使用自增 id,而不是跟随原有评论的 cid 来产生新的评论 id,因此这次评论表的主键是 id,原有的评论 id 只作为其中的一个字段 wid 来构造楼中楼的关系,这些旧评论插入到数据表时都会有新的评论 id;

  3. 楼中楼的评论是处在某个评论下的,同时,楼中楼里还有相互之前的互动回复。因此这个评论的 pid(parentid)表示当前评论处于哪个评论之下,同时 replyid 表示是回复的哪个评论;若直接回复的父级评论,则 pid 与 replyid 相同,都是父级评论的 id,若回复的不是父级评论,则 pid 为父级评论的 id,replyid 为回复评论的 id;pid 或 replyid 为 0 时,则表示直接对文章发表评论。

因此我们的评论表是这样设计的:

字段类型说明
idint自增,主键
widint评论原有的主键 cid
uidint用户 id
replyidint该评论回复的评论 id,没有则为 0
pidint该评论所在的父级 id,没有则为 0
aidvarchar(100)文章的标识
contentvarchar(300)评论内容
createtimeint评论时间的时间戳

表中的 aid(文章的标识)可以是文章的 url,文章的 id 或者其他任何能够唯一识别该文章的东东都可以。这里我们使用的是文章的 uri 来作为唯一标识,比如上面数据中的文章,我们使用/node/2017/02/20/node-express-forum.html来标识文章。其他文章同理。

将这些评论写入表时,我们还要注意的是,原数据中,每个评论都对应着一个用户,在我设计的系统里,用户与评论分来了,只使用 uid 来进行关联。新的用户与新的评论都是使用自有的自增主键,因此在原有评论进行入库时,需要将原来的 userid 转换为新用户表中的主键 id,新旧数据进行统一。

如何实现一个楼中楼的评论系统-蚊子的前端博客

文章表不做解释。

3. 具体实现

前端部分主要是负责展示每个文章的评论,同时让登录用户可以添加评论。

3.1 展示评论

我们已经对每个评论都添加了文章标识,前端只要根据 aid 就能拿到当前文章所有的评论。不过我们的评论是要楼中楼的方式展示的,不能一股脑的把数据平铺到页面中。我们在 2.2 中也说了,pid 为 0 的评论都是直接对文章进行评论的,这些评论应该是作为一级评论展示的;pid 为其他数据的,必然是属于某个评论之下,应当作为楼中楼展示。

同时,无论一级评论,还是楼中楼的评论,都有可能产生分页的情况,因此这里也要做好分页处理。

那么最终,我们前端拿到的结构应该大致是这样的:

COPYJSON

{ "code": 0, "data": [ { // 一级评论 "id": 1, "content": "蚊子的博客棒棒的", "createtime": "2017年08月08日00:26", "nickname": "匿名者", "reply": { // 楼中楼 "data": [ { "id": 1, "content": "谢谢,一起学习", "createtime": "2017年08月08日00:36", "nickname": "蚊子" } ], "page": { "cur_page": 1, "all_page": 1 } } } ], "page": { "cur_page": 1, "all_page": 1 } }

前端拿到接口返回的数据后,就可以渲染页面了。在头像的处理上,也考虑到了 https 的环境,因此返回的头像链接都是//开头的形式。

3.2 参与评论

用户对文章或者某个评论产生了共鸣,需要留言讨论一番,我们就需要用户能够把自己的评论也添加进去。

评论的类型,细分的话,可以分为 3 类:

  • 直接对文章发表评论,pid 与 replyid 为空;

  • 对一级评论进行回复,pid 与 replyid 均为一级评论的 id;

  • 对楼中楼进行回复,pid 为一级评论的 id,replyid 为你回复的评论的 id

我这里前端的实现参考了 oschina(开源中国)的评论方式。直接对文章评论,是直接在顶部的评论窗口进行输入;对其他评论进行回复时,采用弹窗的方式来进行回复。弹窗回复的好处就是,页面不用滚动,用户对某个评论的感知也能停留在这个位置;同时也不用增加各种不必要的小输入框来让用户输入评论。

3.3 登录

在登录问题上,我也是纠结了不少的时间,究竟是使用自己的登录系统呢,还是使用第三方登录呢,或者是用户不用注册登录,只要输入邮箱和昵称就能进行评论呢?

使用自己的评论系统,那么就需要开发一套注册和登录流程,开发麻烦,而且对于想要回复一句话的用户来说,可能就直接放弃注册了;若只要输入邮箱和昵称就能评论,我考虑到可能会引起用户的无限评论,无法控制。因此,最后还是考虑接入第三方的登录,这里选择了使用微博作为第三方登录的入口,后续会考虑加入 github 的帐号登录。

关于如何接入微博的第三方登录,我们下篇文章再讲,文档齐全,对不熟悉的开发者来说,刚开始可能有点懵逼,不过应该问题不大。

3.4 添加邮箱功能

用户在第三方登录成功后,在名字旁边有个小的 input 输入框,可以让用户输入邮箱来接收回复提醒,这个输入完全是自愿的,不输入邮箱也依然可以评论。也是考虑到本站是个小站,访问量极低,用户可能一时兴起评论了两句,事后又想起这个网站来,又不知道怎么找了。因此就想着添加一个邮件提醒功能,不让大神的评论石沉大海。

3.5 特别注意

在刚开始实现完成评论功能的时候,用户只要进到这个页面,评论就会加载。但是有个问题就是,用户不一定会把你的文章看到底部,不一定就看你的评论。因此后来文章就改成了按需加载,只有用户滚动到底部,有想要看评论的意向时采取加载评论。

最终展示的效果就是这样:

如何实现一个楼中楼的评论系统-蚊子的前端博客

4. 总结

作为一名前端开发,用仅有的后端知识开发一套博客的评论系统,显得是非常的简陋,整个框架的设计感觉也是很糙。同时缓存系统用的不熟练,不能做到评论信息的立即更新。这个系统依然还有很多改进的地方。欢迎大家对蚊子多多提意见和建议。

在写这篇文章的时候,想着是以后要改版的时候,可以做成评论同步加载的方式进行。生成后的文章,更新频率极低,甚至不太变动,那么缓存的就是评论的内容,每当有新的评论时,就删除当前文章的缓存,重新加载新的数据,然后再缓存上新的数据,这样在评论数据更新比较低的时候,可以缓存的时间更长,同时也有利于搜索引起对评论内容的抓取。

标签:
阅读(2514)

公众号:

qrcode

微信公众号:前端小茶馆

公众号:

qrcode

微信公众号:前端小茶馆