基于TypeScript的Redux简介

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

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

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

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

2. 重构不灵活： 传递inputs属性时要贯穿整个组件树，从而致使父子组件之间产生藕合，而这些
   藕合一般都是没必要要的。这样，试图把一个子组件放入组件树的其余层级中会变得很是困难，由于咱们必须修改全部的父组件来传状态。

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

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

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

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