React實戰-ReactJS+Redux的思考
ReactJs的官方架構是：ReactJs+Flux。然而作爲Flux的升級版，ReactJs+Redux越來越流行，已經有超越ReactJs+Flux的趨勢。到底哪種更好，則又是一個仁者見仁、智者見智的事了。但是無論你是否採用Redux，最好還是看看Redux的使用方式，如果能看看Redux的實現方式，將收益匪淺，那是將重構運用的令人敬佩的實際案例(微信：react-javascript)。
1.Redux誕生的原因
對於Redux作者的動機，我也是深有感觸的和認同的。採用ReactJs後，我們的確將頁面元素都組件化了，大到整個應用，小到一個按鈕都是一個個組件，但也帶來了相應的問題，太多的狀態需要維護，太多的事件關聯，再加上對ReactJs框架不熟悉，出現各種不倫不類的編程方式，隨着程序代碼不斷增加，你會感覺慢慢失控，尤其是在規範性不強的開發組裏，同樣的一個操作，可能每個人的做法都不一樣，給項目帶來了極大的風險。Redux作者認爲最大的風險是：可變性和異步。Redux作者想解決的最重要的是這兩個問題，結果如何，只能說Redux作者確實是個大師，在看來Redux最終的實現方式時，你會覺得在封裝和解耦這兩點做的了極致。
2.Redux的三原則
Redux作者定義了Redux的三原則，這也證明了Redux作者的大師級水準。Redux有以下三個原則：
a.整個應用的state以對象樹的形態存在一個store裏。
這裏關鍵有兩點：一是在Redux中所有的state存在一個對象樹裏；二是state存在store裏。Redux作者的觀點是這樣簡單，易調試、跟蹤，開發快、並且使得傳統方法很難實現的操作現在很容易了，例如Undo/Redo之類的操作。
對於這一點還真是出乎我的意料，在Flux中雖然state存在於store中，但是在各個組件裏也存在大量的state，這種集中將state存在於store中,並且只構建一個state對象的想法跟單頁面的想法一樣大膽。但是相應的也就帶來了很多約束，程序員的自主性也少了。可能這就是簡單與靈活的兩難取捨吧。
b.State是隻讀的
只有通過action一個方式才能改變state。這在Flux中基本也採用這種方式實現對store中數據的操作，然而在頁面組件中則自由的多。Redux採用這種方式基本上是強行迫使你採用單向數據操作方式，但是給人的感覺有點像帶了一副枷鎖，限制了你的自由。
c.變化均採用了純函數式編程
全部採用純函數式編程，好處自然是純函數編程的好處，對於這種好處，我感受並不深刻，但是這種純函數編程的寫法還是與普通寫法有很大的不同。我一直懷疑這種純函數式編程方式的性能是否受到較大影響，尤其是在數據集操作過程中，是否明顯，沒有測過，也就沒有發言權了。
3.是否採用Redux
是否採用Redux？這是個問題，正如Redux作者所說，Redux可以看作是Flux的實現，也不全是。Redux來源於Flux，使得模式更簡單，在這中簡化過程中又增加了一些自己的規則。
4.Redux中的純函數編程
純函數編程是Redux與Flux在編程方式中的重要區別，首先看看純函數編程的要點：
a.同樣的輸入，得到同樣的輸出
b.操作不受邊界影響
c.不依賴外部狀態。
純函數編程通俗的講，函數操作過程不受外部影響，同樣的輸入不會因執行次數不同而不同，在store中最多的是對數據對象和數據對象集的操作，如何才能做到是純函數編程，有一些通用的技巧，儘量採用Array的map(),filter(),concat(),slice()和...spread操作來實現，避免直接對Array參數的元素直接操作。
以下爲添加和修改操作的純函數式編程方式。
1）.添加操作
Function addText(state,action){
Return [
...state,
{
Id: action.id,
Text: action.text,
Completed:false
}
]
}
2）修改操作
Function modifyText(state,action){
Return state.map( (t, action => {
if (t.id !== action.id) {
return t
}
return {
...t,
completed: !t.completed
}
}
)
}
以上操作基本體現了純函數式的不同編程方式。
5.結束語
最終是否採用Redux，這確實是個問題，在Facebook的一個社區統計結果來看，用的人還是佔大多數，每個人的情況不一樣，無所謂多好多壞吧，it’s up to you。