本章以及下一章将着眼于一种叫做Redux的数据架构。
我们将开始讨论Redux的背后原理，建造一个自己的迷你版Redux并把它连接到Angular上。

到目前为止，我们的大多数项目都在通过一种相当直接的方式管理状态： 从服务器获取数据，
然后在组件中渲染数据。在组件中，值是沿着自上而下的方向传递的。

对于比较小的应用来说，这种管理方式已经足够了： 但是随着时间的成长，让多个组件来管理
状态的不同部分将变得难以处理。比如通过组件树，向下传递所有值的方式有以下缺点。

1. 属性的间接传递： 为了让任何组件都可以获取到应用的状态，我们不得不通过inputs属性向下传递值。这意味着我们会借助很多中间组件来传递状态，而这些中间组件既不使用，也不关心传递的状态。

2. 重构不灵活： 传递inputs属性时要贯穿整个组件树，从而导致父子组件之间产生藕合，而这些
   藕合通常都是不必要的。这样，试图把一个子组件放入组件树的其他层级中会变得非常困难，因为我们必须修改所有的父组件来传状态。

3. 状态树和DOM树不匹配： 状态的“形状”往往和试图／组件层级的“形状不匹配”。当我们需要引用组件树中一个较远分支中的数据时，通过组件树的属性来传递所有值就会使我们能陷入困境。

4. 应用中到处都是状态：如果通过组件管理状态，就很难获取应用整体状态的快照。因此也就很难知道知道哪个组件“拥有”一条特定的数据以及哪些组件关心该数据的变化。

把数据从组件中提取出来并放到服务中会有很大的帮助。至少，如果服务是数据的拥有者，那么对于把数据放在哪里，我们就有了更加清晰的认概念。但是这样也带来了一个新问题： 关于“让服务拥有数据”的最佳实践是什么呢？有什么可遵循的模式吗？ 当然有。

Redux的设计初衷就是为了解决这样的问题，把所有的状态都存储到一个地方。这种把所有的状态都存储到一个地方的想法咋看起来非常疯狂，但是终会给你很大的惊喜。