基於TypeScript的Redux簡介

本章以及下一章將着眼於一種叫作Redux的數據架構。
咱們將開始討論Redux的背後原理，建造一個本身的迷你版Redux並把它鏈接到Angular上。

到目前爲止，咱們的大多數項目都在經過一種至關直接的方式管理狀態： 從服務器獲取數據，
而後在組件中渲染數據。在組件中，值是沿着自上而下的方向傳遞的。

對於比較小的應用來講，這種管理方式已經足夠了： 可是隨着時間的成長，讓多個組件來管理
狀態的不一樣部分將變得難以處理。好比經過組件樹，向下傳遞全部值的方式有如下缺點。

1. 屬性的間接傳遞： 爲了讓任何組件均可以獲取到應用的狀態，咱們不得不經過inputs屬性向下傳遞值。這意味着咱們會藉助不少中間組件來傳遞狀態，而這些中間組件既不使用，也不關心傳遞的狀態。

2. 重構不靈活： 傳遞inputs屬性時要貫穿整個組件樹，從而致使父子組件之間產生藕合，而這些
   藕合一般都是沒必要要的。這樣，試圖把一個子組件放入組件樹的其餘層級中會變得很是困難，由於咱們必須修改全部的父組件來傳狀態。

3. 狀態樹和DOM樹不匹配： 狀態的「形狀」每每和試圖／組件層級的「形狀不匹配」。當咱們須要引用組件樹中一個較遠分支中的數據時，經過組件樹的屬性來傳遞全部值就會使咱們能陷入困境。

4. 應用中處處都是狀態：若是經過組件管理狀態，就很難獲取應用總體狀態的快照。所以也就很難知道知道哪一個組件「擁有」一條特定的數據以及哪些組件關心該數據的變化。

把數據從組件中提取出來並放到服務中會有很大的幫助。至少，若是服務是數據的擁有者，那麼對於把數據放在哪裏，咱們就有了更加清晰的認概念。可是這樣也帶來了一個新問題： 關於「讓服務擁有數據」的最佳實踐是什麼呢？有什麼可遵循的模式嗎？ 固然有。

Redux的設計初衷就是爲了解決這樣的問題，把全部的狀態都存儲到一個地方。這種把全部的狀態都存儲到一個地方的想法咋看起來很是瘋狂，可是終會給你很大的驚喜。