一句話總結flux，以及咱們爲什麼須要flux

若是讓你用一句話總結一下什麼是flux，該怎麼說？

官網上有這樣的介紹：flux是一種思想，一種框架，是facebook給react。。。

這樣的解釋對程序員來講，顯得過於抽象又不具體了。

阮老師的文章，也將官網的介紹很好的翻譯了一遍。讀了之後能夠了解到flux是由哪些部分組成（store，dispatcher，action，view）。但就算知道了這些，仍是無法很好的解答程序員同窗們心中的疑惑，flux究竟是什麼，用來作什麼的，爲何用它，用它有什麼好處呢？

若是有一本歷史書，寫了flux誕生的各個事件，也許事情就沒那麼複雜了。如今沒有這本書，咱們使用flux的過程，就像是盲人摸象。那麼如今，摸了好久，摸了不少次，很全面的摸過這個大象之後，咱們來總結一下咱們摸到了什麼吧。

1.flux是一個數據中間層，用於規範的管理數據，這些數據每每以狀態(state)來呈現。

2.flux不是必須的，但當你使用react或vue等組件化的mvvm框架的時候，flux彷佛變得特別的順手起來。

3.越是複雜的業務邏輯、數據處理、數據模板，越是將你快速的送到flux面前。

總結到一句話就是：flux是一個善於對複雜數據模型進行規範管理的中間層，而且它與組件化的mvvm框架有互補做用。

複雜是一個相對的概念。那麼複雜到什麼地步，咱們就須要flux了呢？

來看一個例子：

假定組件化開發程序中，三個不一樣層級的組件使用了同一個數據對象做爲數據模型的一部分。三個組件對共用的數據對象各有操做，又互相影響。

這種狀況下有兩個比較嚴重的問題：

1.三個不一樣組件對數據對象的操做各不相同，操做部分因各個組件環境不一樣，操做代碼將與組件自身的業務代碼混在一塊兒。不方便後期維護。

2.換個程序員就很難找齊操做過這部分數據的三個不一樣位置的組件，以及組件中操做數據的各行代碼了。

而使用flux能夠統一數據操做接口（action，dispatcher），方便查找操做數據的入口（調用了相同的action/dispatcher），這就解決了上邊提出的兩點問題，加強了數據的可維護性，可擴展性。

再來看一個例子：

例子叫作狀態管理好了：一個組件，要undo，redo，進入不一樣的歷史狀態。

用戶能夠手動構建單獨的狀態管理器，而flux能夠經過store，dispatcher，action輕鬆的實現對狀態數據的管理。從這個角度來看，flux又能夠被看作是一個複雜狀態管理器，只不過flux不侷限於管理組件的狀態，而是更深層次的將數據與狀態視爲一體。從mvvm的角度來看，管理數據也是在管理狀態。

so, flux帶給咱們的是一種面對複雜問題的解決方案，你get到了嗎？