这篇文章更多地讨论了我在构建应用程序时遇到的当前问题。我很想听听不同的人对他们如何实现这一点的看法:)我使用redux作为例子,但这个问题确实扩展到所有前端状态管理。 / p>
我正在构建一个应用程序,它是一个分页的新闻源类型列表,一次加载结果10个帖子。当我到达该列表的底部时,它将获取另外10个帖子并附加到列表中。
我将我的状态管理为帖子的散列和分页ID的列表。每当我到达列表的末尾时,我都会从偏移量中获取下一组结果,并将新的ID推送到列表的末尾,这一切都很有效。
{
posts: {
a: {
content: 'some content'
points: 100
},
b: {
content: 'some other content'
points: 98
},
c: { ... },
d: { ... },
e: { ... },
.
.
.
},
popularPosts: [
'a',
'b',
'd',
'e'
.
.
.
],
newPosts: [...]
}
问题在于我有功能可以在列表顶部进行刷新并获取最新的帖子(就像你在Twitter或9gag应用程序中那样)。
问题在于按点排序是动态的。因此,例如,在第一次请求时,按上述点排序的帖子是[a,b,d,e]。现在,如果人们在投票后发布了什么,那么会发生什么?几点,现在当我下一次刷新时,服务器上的顺序是[b,a,d,e]。我可以天真地找到服务器中的新命令和状态中的现有顺序之间的公共序列,并将差异追加到列表的顶部,但这是一个非常基本的示例,您可以看到高容量应用程序状态将很快变得不同步并引入潜在的重复。
从应用程序中已加载的帖子中尽可能多地缓存并尝试找出我可以协调的现有分页ID列表中的位置/方式会很好。简单的解决方案是擦除状态并重新开始,我只是想知道是否有人有这方面的经验以及他们是如何解决的?
答案 0 :(得分:0)
很好的问题,就我而言,每次刷新时,我都会使用Array.sort并给它我的compareFunction,所以我的10个帖子中的元素将按照我的意愿排序。
答案 1 :(得分:0)
我遇到过类似的困难。所以基本上,你可以用两种可能的方式修改你的状态:1。分页和2.拉动刷新。
假设您有两种不同的操作:FETCH_POSTS_SUCCESS
用于分页,FETCH_POST_REFRESH
用于刷新。
每当你触发FETCH_POSTS_SUCCESS
动作时,你应该追加下一个10个帖子ID,当FETCH_POST_REFRESH
动作被触发时,你刷新状态数组并追加服务器本身上的前10个帖子ID 。刷新时不需要保留分页ID,只需在初始化时和刷新时只需要前10个ID。
答案 2 :(得分:0)
我将尝试发布自己的解决方案,并对其进行一些建设性的批评:)为了使我的解决方案易于遵循,我将使用4个帖子而不是10个页面大小。 / p>
假设我们有一个包含10个帖子的列表(在此示例中为3个页面加载)
id | points |
-------------
a | 100
b | 90
c | 87
d | 43
-------------
e | 30
f | 12
g | 5
h | 4
-------------
i | 3
j | 3
现在让我说我下拉刷新,我得到另外4个帖子,结果如下(其中一些已经缓存,但很明显有陈词滥调)
id | points |
-------------
g | 120
z | 115
h | 113
e | 112
我知道我对这些结果进行了排序,并且我知道我的缓存结果已经排序,因此我需要做的就是从我的缓存集中提取任何常用键(我甚至可以从我的问题中查询我的posts
哈希建立一个搜索候选列表,而不是为每个项目迭代)。当这些ID被拔出时,我的缓存条目应如下所示。
id | points |
-------------
a | 100
b | 90
c | 87
d | 43
f | 12
i | 3
j | 3
现在我知道我的 new 结果集的点数高于我的缓存集,所以我只是将它们叠加在顶部给我
id | points |
-------------
g | 120
z | 115
h | 113
e | 112
a | 100
b | 90
c | 87
d | 43
f | 12
i | 3
j | 3
所以我现在唯一的问题是确定与缓存结果不同的新结果数是否大于页面大小,以及在我同步所有内容之前我在另一个页面获取的标准。我可以天真地继续抓取,直到我的 new 结果集的序列与我的缓存结果集中的序列匹配
我知道这里有很多边缘情况,只是想进行大脑转储:)