如果讓你用一句話總結一下什麼是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到了嗎？