Flux 是什麼？
Flux 是一種架構思想，專門解決軟件的結構問題。它跟MVC 架構是同一類東西，但是更加簡單和清晰。
Flux存在多種實現：
Flux將一個應用分成四個部分：
View： 視圖層；是用戶看得見摸得著的地方，同時也是產生主要用戶交互的地方，這個概念在 MVC 和 MVVM 架構中都是有的，有些觀點認為雖然這幾種架構裡都有 View，但是定義不太一致，有細微的差別，我自己覺得這種差異確實是存在的，但在一開始這並不妨礙我們理解 View 這個名詞。
Action（動作）：視圖層發出的消息（比如mouseClick）；就是一個結構化的信息，從一個地方傳遞到另一個地方，整個過程就是一個 Action/Event。
Dispatcher（派發器）：用來接收Actions、執行回調函數；Dispatcher 算是從 Action 觸發到導致 Store 改變的鎮流器。比一般架構設計裡直接在“Event”邏輯中修改“Data”更“正規”。
Store（數據層）：對應我們傳統意義上的 Data，和 MVC、MVVM 裡的 Model 有一定對應關係，用來存放應用的狀態，一旦發生變動，就提醒Views要更新頁面
基於 Servlet 容器的 Web MV
對 Web 開發者來說，Spring 中的 Web MVC 框架，也一直隨著 Spring 而成長，然而由於基於 Servlet 容器，早期被批評不易測試
實現 Reactive Streams 的 Reacto
Web Flux 不依賴 Servlet 容器是事實，然而，在談及 Web Flux 之前，我們必須先知道 Reactor 項目，它是由 Pivotal 公司，也就是目前 Spring 的擁有者推出，實現了 Reactive Streams 規範，用來支持 Reactive Programming 的實作品。
但是，從實操 Controller 介面搭配 XML 設定，到後來的標註搭配 JavaConfig，Web MVC 使用越來越便利。如果願意，也可採用漸進的方式，將基於 Servlet API 的 Web 應用程序，逐步重構為幾乎沒有 Servlet API 的存在，在程序代碼層面達到屏蔽 Servlet API 的效果。
由於不少 Java 開發者的 Web 開發經驗，都是從 Servlet 容器中累積起來的，在這個時候，Web MVC 框架基於 Servlet API，就會是一項優點。因為，雖然運用 Web MVC 編寫程序時，可做到不直接面對 Servlet API，然而，也意味著更強烈地受到 Spring 的約束，有時則是無法在設定或 API 中找到對應方案，有時也因為心智模型還是掛在 Servlet 容器，經驗上難以脫離，在搞不出 HttpSession、ServletContext 對應功能時，直接從 HttpSession、ServletContext 下手，畢竟也是個方法。
編寫程序時，就算沒用到 Servlet API，Web MVC 基於 Servlet 容器仍是事實，因為，底層還是得藉助 Servlet 容器的功能，例如 Spring Security，本質上還是基於 Servlet 容器的 Filter 方案。
然而在今日，Servlet 被許多開發者視為陳舊、過時技術的象徵，或許是因為這樣，在 Java EE 8 宣佈推出的這段期間，當在某些場合談及 Servlet 4.0 之時，總會聽到有人提出“Web Flux 可以脫離 Servlet 了”之類的建議。
示例：
如果按領域拆分store，那對應reflux和redux：
reflux下可以放在View層，讓component去管，而這個開閉狀態本質上和POST_TODO_COMPLETED 這個action是有關的，想要實現這個功能，就必須讓UI層直接監聽請求成功的Action。
通常在reflux中我們會利用異步action的triggerPromise，在view層
當然，這顯然違背了FLUX的 數據流，算是action和view的私相授受。在redux中，由於沒有triggerPromise這樣的“後門”，domain則是和頁面無關的，這個矛盾很難調和：兩個頁面展示和操作同一個領域對象，卻有完全不同的展現和行為，這樣的場景並不少見。
如果總結一下的話，大家應該會有一種感覺，前端開發在很長一段時間內是服務於後端的，因此在框架、概念上都有頗深的後端印記，而FLUX、Redux們的出現，代表著開發者們真正從前端的角度在思考、組織和前進。
總結
Flux 帶來的好處就是，發生的任何事情都在 dispatcher 中提前定義好了（沒定義的話就 不會發生任何事情），所以任何事件都是可預測的。
閱讀更多 咱小二 的文章
