剖析Twitter的Redux Store结构

可能你还不知道，Twitter的移动网站使用了一个新的web堆栈，里面包含了React和Redux。

在听说了这个消息之后，我决定要仔细研究一下他们的Redux store，看看他们是如何在state tree中安排所有推文的。

要想查看Redux store，你需要现在Chrome中安装React Developer Tools (RDT)，然后在RDT标签下选取程序的root元素，并且在控制台中输入下面的这条命令：

// $r is a shortcut that references the selected element in RDT
$r.store.getState(); 

之后你就可以在控制台中看到Redux的state tree了：

我推荐你花时间研究一下所有的state slice，但是我现在只关注entities/tweets和homeTimeline。因为这两个slice里包含了大多数与推文相关的数据。

所有详细的推文数据都储存在entities/tweets/entities里，他们都以规范化数据表的形式出现，每一条推文都是一个对象。我站看了列表中的第一条推文，供你仔细研究：

homeTimelines/timeline这个slice负责展示你Twitter账户的时间轴。这个时间轴按照数字有小到大进行排列，第一个对象的编号是0。时间轴中的每一条推文都拥有tweet id，它和entities/tweets/entities数据表中的key吻合。

看上去这个时间轴通过top和bottom来追踪推文，top = 新推文, and bottom = 老推文。lastFetch.bottom和lastFetch.top都有一个date stamp，它的作用是显示推文最后一次被取回的时间。当有新推文进入的时候，他们会被加载到top上，而bottom中的推文会进入时间轴的滚动条中。

cursor.bottom和cursor.top代表的是推文的id，而这个id代表的是这条推文在时间轴的top/bottom位置。

最后我还发现了另一个有趣的东西，在entities这个slice下，你会发现除了tweets之外，还有cards, lists 和 users。这四个东西在展开以后，你会发现他们都使用了相同的架构，并且都包含fetchStatus。这里面一样有一个数据表，他们的key是推文的id，值是获取状态——在我的例子中所有推文都为“loaded”。由于我从来没有看到过loaded之外的状态，因此我只能对其他状态进行猜测。我猜他们还有一个状态应该是loading，这个状态可能是在下列情况中会出现：

如果一条推文已经被取回或是正在loading，确保对同一条推文的复制请求不会进入服务器。

无需将推文的详情从entities中调取的情况下，允许在时间轴上开始渲染。

我推荐所有对Redux有兴趣的人都来研究一下这个应用，你会在里面发现很多东西。我认为，Redux将会大规模的被用在web应用上。

原文来自:SDK.cn

声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com