react 與 flux 的搭配算是目前正興起的一像前端開發手法
flux 是 Facebook 提供的一套前端設計模式，也可以說是一個架構
react 就不多說了，之前有文章介紹過了，去年看到 flux 的架構設計之後
特別有看到 Facebook 的介紹有提到，他們認為 flux 的架構設計是比較適合大型的前端應用的
另外也有提到前端 MVC 架構中的一些缺點，我是有部分認同他們給出來的一張圖
上面這個例子或許是大多數大型前端應用會遇到的難題，這已經跟 MVC 用不用得好沒關係了
在這之前曾經寫過大型的 backbone 程式，寫到最後(Model & View)就真的跟上面有點╰(〒皿〒)╯
雖然後續我認為 backbone 不能很根本地稱做 MVC，至少要額外加入 marionette 與 stickit
透過 marionette 補足 Controller， 並利用 stickit 來實現 Model 與 View 之間的 two-way binding
最後就是利用 backbone + marionette + stickit 實作出以 MVP 模式為主的架構
但無論如何 Model 與 View 之間總是存在著複雜的依賴關係或是事件傳遞
儘管前端用 RequireJS 和 Backbone 本身的 Event 機制，總是無助於那 Model 與 View 間錯綜複雜的關係
而從 flux 的架構來看，卻實會好一些嗎？我們可以先看 flux 的架構：
flux 的重點在於他架構中的資料流只有單向的，並不像前面那張圖中 Modal 與 View 存在複雜的雙向關係
在 flux 剛推出的時候，一開始質疑的聲音其實蠻多的，先撇開這些質疑的部分不談
底下我用比較簡單的方式來描述 flux，因為我覺得 flux 的原圖會讓人有"誤會"
上面第一張圖主要是描述 flux 的架構設計層面，簡單說 View 接收到一個使用者行為後
透過一般函式呼叫的方式呼叫 Action，而 Action 則會透過 Dispatcher 觸發一個事件
Store 要扮演的腳色就是聆聽想要的事件並處理相關的業務邏輯或資料處理，完成後觸發資料變化的事件
最後就是 View 只需要聆聽資料變化的事件並進行畫面的更新
上面第二張圖則是實際資料流，這我就不多說了，應該很清楚才對
說到這邊，我是認為 flux 其實跟 MVC 或 MVP 蠻像的，至少個75 ~ 80%吧....
所以對於本篇文章的第一張圖，我是覺得 flux 原則上只是將 Modal 與 View 之間的關聯簡化到只有單一方向的資料流
但這就是 flux 的最大的差異點，它的資料流永遠只有單一方向的
因此另一個特點就是 Store 是內聚的，沒有任何元件可以更改 Store 內的資料
也就是說 Store 與 View 和 Action 間彼此是不互相影響的，因此會降低資料與模型間的複雜度
另外 Dispatcher 在 flux 的設計中就是一個 singleton 的元件，只負責 Action 與 Store 間的事件派送
這個設計我覺得是沒什麼問題的，當然如果沒有 Dispatcher ，讓 Action 與 Store 直接做事件的傳送也是可以
但要設計得當，否則會讓 Action 與 Store 有太多的耦合關係
目前來說 flux 與 react 的搭配是值得學習的，與 AngularJS 相比
react/flux 的架構相對來說比較透明且簡單理解，怎麼說?
因為 flux 的流程是單向的，你會更好更容易的掌握資料的變化，在大型應用中
對於程式的位置或是在 debug 上，相對於 AngularJS 來說更為容易，但這並不表示 AngularJS 不好
而是 AngularJS 在大型應用的開發中會很複雜，在 debug，trace code 與設計方面要花很大的心思
畢竟要把 AngularJS 學好並不是件容易的事情，當然我們也可以期待 AngularJS 2.0 的表現了
沒有留言:
張貼留言