Flux的價值?

Flux是Facebook提出來的資料流模式，號稱這樣能夠更好維護，結構更清楚，因為採用了單向流程，但實際上並沒有人真正說出價值在哪，到底為什麼更好維護或更清楚，甚至使用了很有爭議的圖來說明，就連作者也承認下圖的確有爭議。

而很多講Flux相關的文章跟圖片，反而讓我感到更疑惑了，它們都故意將案例簡化後營造出讓你看起來真的更簡單地的樣子。

難道Action不會被共用?一定會的阿，當你一堆View都用一樣的Action，回來的Store也被很多View使用，這樣就不會混亂?所以這篇文章所說的Flux並沒有比較簡單，我就比較能接受。

換個角度來說，也許是我寫的是Android所以比較難體會React的痛點與問題，以Android來說每個畫面都會有一個Activity，跟這個畫面有關的邏輯與資料流都會發生在這個Activity之內，也就是說Android的架構本身就已經先把範圍縮小，簡化了問題，而在Web採用SPA的開發方式，並沒有這樣的架構?所以需要透過這樣的方式去簡化?React沒有解決這個問題嗎?在Angular2中可以將Component當成一個畫面的主Component，裡面再透過小Component組出畫面，這樣就可以做出像Android的概念將畫面模組化，基本上就不會有複雜到難以維護的問題，再從另外一個角度思考，也許JavaScript不是靜態強型別的語言，不像Java要找出referencec是非常容易的事情，所以只好透過單向數據流減少找問題的時間?

Android其實也有類似Flux機制的東西(還是會有實做上的不同)，就是EventBus or Android BroadCast & BroadcastReceiver，不過他們本質上其實跟callback listener一樣是觀察者模式，只不過實作上有點不同，那Android中使用EventBus的好處是甚麼呢?最大的好處就是不用傳遞callback listener，只要在需要接收的地方訂閱，然後需要做事時發送訊息就好，但如果過多的使用，到底哪些地方註冊的，又是由哪些地方發布的，這樣是否更加混亂呢?如果再配上Android的生命週期，真的簡化了問題嗎?

上圖出處，這張圖就是我認知比較正確的全貌，其實單向流最主要打的問題點是two way binding的混亂，但是two way binding就是用來省自己做two way binding的工阿，Angular2也讓我們可以選擇是否要two way binding，不過如果選了React官方也只有Redux可以選就是，雖然有聽說過社群有人做React的two way binding框架，最後其實這篇文章只是簡單紀錄一下前陣子的思考，最後我還是沒找到Flux的價值，也許未來有甚麼樣的需求時，我會發現它的價值吧!