关注列表按最后回复时间排序

[Yixuan-Wang]

关注列表按最后回复时间排序

[Yixuan-Wang]

也就是说，需要在回复加载完毕后，从子组件向父组件传值，触发父组件重新加载？

[AllanChain]

实现起来的确有点麻烦。。我觉得尽量不要先渲染，因为费时间

[Yixuan-Wang]

我觉得尽量不要先渲染

指的是尽量不要先渲染关注列表？还是回复？

[AllanChain]

等等，渲染的时间和网络 IO 时间相比应该还是网络时间长吧（上面好像讲错了）

还是感觉渲染的时间要长，不使用 LazyLoad，对 2500 条回复逆序重新渲染耗时约 10 秒，使用 LazyLoad 耗时约 2~3 秒。刷新回复耗时约 4 秒（刷新耗时里包括多少渲染时间还两说）。

主要还是时间问题。而且 cache 在获得回复之前就知道是否需要更新，有没有可能操作一波。。（比如 StaleWhileRevalidate 的感觉？先返回是否过期，再异步更新？） 问题是知道要更新并不是知道排第几啊。。

[Yixuan-Wang]

思考了一下这个功能的实现……

目前时间线相关组件的层次结构：
Flow - FlowChunk - Context.Consumer - LazyLoad - FlowItemRow - FlowItem / Reply

洞的数据在 Flow 中获取，向右一层层传 prop，一直传到 FlowItemRow，也就是包含洞和全部回复的组件，在这一层才获取回复数据，并且计算最后回复时间，存储在 FlowItemRow 的 state 中。

如果不改变上述流程：
要想让 Flow 层拿到最后回复时间，可能的解决方案：

1. 一层层回调（太可怕了）
2. 用一个外部的 store 做简单的状态管理

另外，各个洞最后回复时间的计算也不是同步的。还需要确认所有的最后回复时间都已经计算完毕，才能考虑重新排序的问题。

假设 Flow 层能拿到最后回复时间，由于是要按最后回复时间排序，因此需要对洞的数组重新排序，改变 Flow 的 state，组件重新渲染。回复数据如果重新再获取一次，浪费了性能，因此之前回传的数据也应当包括所有的回复。但这样两次渲染（获取回复的渲染和重排的渲染）数据源完全不一样，整个组件的逻辑就有些混乱了。

如果改变上述流程，把加载回复挪到 Flow 中进行（也就是从异步获取回复变成同步获取），如果是从缓存中读取速度尚可，如果需要从服务器更新回复（尤其是现在存在神洞级别的置顶洞，第一个洞常常需要从服务器中获取更新），那么渲染过程可能会慢到难以忍受……

[Yixuan-Wang]

前端实现这一功能，感觉难度较大。

T大树洞提出的后端解决方案似乎更加简便易行：

[后端]增加一个column叫last_reply_timestamp即可

但根据官方鼓励树洞沉下去的原则，官方维护的后端可能不会增加这一功能。

[Yixuan-Wang]

个人认为，关注列表分组更为可行，而且可能优于按最后回复时间排序的方式，参见 #35 。

[AllanChain]

但根据官方鼓励树洞沉下去的原则，官方维护的后端可能不会增加这一功能。

虽然但是，这会耽误事啊

---

（虽然工作量，但是）我的想法是，数据放到 Flow 中，返回一个 load_replies_with_cache 的 Promise（如果频率过高，可能还要依次加 setimeout）。每个 FlowItem 在 Promise resolve 之后更新状态，Flow 则在所有都 resolve 后顶部显示按钮重新排序 。

此外，改变 cache 清洗方案，不去除关注的树洞。

还可加个功能是否开启的设置，默认关闭。并说明该功能适用于关注神洞较少的同学。

---

我觉得分组虽然可行，但是用处有限。仍然有关注的树洞有了回复却没发现。