Question

设计一个 Redux 应用往往从思考应用的状态树数据结构开始，它是用来描述你的应用在任何时间点下状态的数据结构。

任何的框架和架构都包含状态。在 Ember 和 Backbone 框架里，状态就是模型（Models）。在 Anglar 中，状态常常用 Factories 和 Services 来管理。而在大多数 Flux 实现中，常常用 Stores 来负责状态。那 Redux 又和它们有哪些不同之处呢？

最大的不同之处是，在 Redux 中，应用的状态是全部存在一个单一的树结构中的。换句话说，应用的所有状态信息都存储在这个包含 map 和 array 的数据结构中。

这么做很有意义，我们马上就会感受到。最重要的一点是，这么做迫使你将应用的行为和状态隔离开来。状态就是纯数据，它不包含任何方法或函数。

这么做听起来存在局限，特别是你刚刚从面向对象思想背景下转到 Redux。但这确实是一种解放，因为这么做将使你专注于数据自身。如果你花一些时间来设计你的应用状态，其它环节将水到渠成。

这并不是说你总应该一上来就设计你的实体状态树然后再做其它部分。通常你最终会同时考虑应用的所有方面。然而，我发现当你想到一个点子时，在写代码前先思考在不同解决方案下状态树的结构会非常有帮助。

所以，让我们先看看我们的投票应用的状态树应该是什么样的。应用的目标是可以针对多个选项进行投票，那么符合直觉的一种初始化状态应该是包含要被投票的选项集合，我们称之为条目[entries]：

当投票开始，还必须定位哪些选项是当前项。所以我们可能还需要一个 vote 条目，它用来存储当前投票的数据对，投票项应该是来自 entries 中的：

除此之外，投票的计数也应该被保存起来：

每次用户进行二选一后，未被选择的那项直接丢弃，被选择的条目重新放回 entries 的末尾，然后从 entries 头部选择下一对投票项：

我们可以想象一下，这么周而复始的投票，最终将会得到一个结果，投票也就结束了：

如此设计看起来是合情合理的。针对上面的场景存在很多不同的设计，我们当前的做法也可能不是最佳的，但我们暂时就先这么定吧，足够我们进行下一步了。最重要的是我们在没有写任何代码的前提下已经从最初的点子过渡到确定了应用的具体功能。