要整合 react 和 flux,並不是用了這兩樣東西就讓你的前端應用完好無缺
這篇先從 react 的角度來看前端元件的開發準則,之後有空再寫點我對 flux 更深入的見解
首先為什麼要用 react 來開發前端,因為前端的所有東西都是元件 (Everything is component)
這也是 react 專注的重點,讓你能夠容易快速的建構一個前端應用
所以當我們透過 react 開發並且把焦點關注在元件(Component)開發上時,有幾個原則是盡量要遵循的
- Composable
- Reusable
- Maintainable
- Testable
在 Facebook 還沒 open react.js 之前,我只認為 jQuery 是最容易做到上述四點的
雖然後續有很多前端的框架 Backbone, Angular, Ember 等等,它們的重點多半是在 MV* 身上
對於一個前端的元件開發而言,它們都並不是非常好用或是友善的。
所以當你在用 React.js 開發前端的時候,也須謹記上述四點,才能讓你用 react 的價值發揮到最大
而除了這四點之外,還有一點是相當重要的,就是 Stateless component
什麼是 Stateless component ?
簡單說就是元件盡量是無狀態的,它不需要處理資料或UI狀態的變化,只要接收資料並呈現就好
所謂的資料就是領域模型(domain model)的資料,例如 Product。這些資料多半是透過 Ajax 或是 RESTful 從後端獲得的。
至於 UI狀態,就是用來"記錄" UI 目前的狀態,比方說哪一個 tab 被選擇,或是哪一個 dialog 被打開 等等。
就一個 Stateless 的設計而言,Composable 的元件是很重要的前提,一個 Composable 的結構會類似如下
在一個良好的 Composable 設計下,我們必須要把需要呈現的資料透過 Root 傳到底下的 component
而底下的 component 只需負責呈現並處理使用者的 action,所以只有 Root 需要 state,底下的只需要接收 props 的資料
這裡的 state 以及 props 就是 react.js 所提供的 state 以及 props
我們知道 react 的 state 是 mutable (可變)的,而 prop 則是 immutable (不可變)的
所以在掌握這個原則下,應該盡量在 Root 使用 state,Root 底下就只接收 prop 的資料並呈現
因此我們可以檢視一下我們的 React 設計,盡量避免以下的情況
也就是說盡可能避免在 Root 底下的 Components 擁有自己的 state,這會讓 Components 富有太多行為,進而更複雜
在一個正確的 Stateless component 設計下,與 flux 組合就更容易掌握
從上圖我們可以看到,Root 底下的 Components 只負責呈現資料,當有使用者的 action 時
不管這些 action 是改變 領域模型的資料或是 UI 狀態的資料,我們都將這些變動行為視為是 flux 中的 Action
透過 Action 到 Store 之後,由 Store 來負責處理這些模型或是UI狀態的資料
例如:使用者可能新增了一筆產品資料又或是他在 UI 上切換了一個 tab
當然可能會有人質疑為什麼連 UI 狀態這些資料也要 hold 在 Store 中
我是認為如果太多的 Component 都不能遵循 stateless 這原則的話
每個 Component 都會因為擁有 State 的情況下,讓該 Component 一定會有很多處理 State 的邏輯
畢竟 State 是 mutable,既然是 mutable,你就必須付出代價去處理它,所謂的代價
就是那些定義在 Component 內的邏輯處理,相對的它會讓你的 Component 不易維護也過於複雜
因此我是認為像類似 哪個 tab 被選擇,或是 list 清單中哪個 item 被勾選,這類的 UI 狀態資料,是可以嘗試放到 Store 的
盡量將他們從 Component 的 State 抽離出來,讓 Component 盡量保持簡單的呈現邏輯就好
當然這是盡量並非一定,所以本篇的結論就像 React 官網所說的
Try to keep as many of your components as possible stateless.
security cctv cameras Karachi, Pakistan
回覆刪除CCTV KARACHI
www.cctvkarachi.pk
sales@cctvkarachi.pk
CCTV KARACHI