我認為MVC模式雖然已經(jīng)誕生了許多年，也有無數(shù)前端框架遵循了MVC模式，但我們在前端開發(fā)時，很多時候還是忽略了這個模式蘊含的思想。該思想的核心就是職責分離，這種分離又隱含了“信息專家模式”的意義，直白地說，就是“專業(yè)的事情應(yīng)該交給專業(yè)的人去做”。
MVC（Model-View-Controller）的三個角色其實是各司其職：
- model持有UI要展現(xiàn)的數(shù)據(jù)
- View即UI的展現(xiàn)
- Controller用于控制
以React來說，它就應(yīng)該只專注于View的呈現(xiàn)，并將這些展現(xiàn)元素封裝為Component。這些Component要展現(xiàn)的props可以視為Model所持有的數(shù)據(jù)。
那么，什么情況下會導(dǎo)致View產(chǎn)生變化呢？從表象上看，似乎引起變化的原因是由于客戶端的某種請求或交互操作產(chǎn)生的事件。實則從業(yè)務(wù)上說，其實就是要改變Model的值，而UI的交互操作不過是對這種變化的界面展現(xiàn)罷了。換言之，View的變化其實應(yīng)該通過Model的變化來傳遞。
當我們需要改變View時，一種做法是直接在View上做文章，通過編寫針對UI元素的控制邏輯去改變View。另一種做法就是遵循MVC模式，應(yīng)該通過Controller去改變Model的結(jié)構(gòu)，然后通知View去改變自己（或者理解為View偵聽到Model的變化，從而改變自己）。
React結(jié)合Redux框架做的正是這樣的事情。在設(shè)計React Component時，我們需要通過UI的Layout來規(guī)劃我們的Component，包括Component的分解與組合。呈現(xiàn)Component的過程就可以抽象為一個函數(shù)，這個函數(shù)接收一個輸入對象model，返回一個包裹了HTML元素與Model的DOM`結(jié)構(gòu)。如以下偽代碼：
const render = (model) => DOM
如果業(yè)務(wù)邏輯要求操作View的DOM，其實就是對DOM包裹的Model進行操作，例如添加或修改某個<li>，其本質(zhì)是要添加或修改<li>元素中的值，這個值來自于Model。在Redux中，其實就是發(fā)起一個action。
執(zhí)行action的目的雖然是修改Model，不過在Redux中，我們盡量希望遵循FP的思想設(shè)計出所謂的“純函數(shù)”，于是Redux就引入了reducer函數(shù)，這個函數(shù)要做的事情其實就是對Model進行transform（可以考慮引入immutable.js來存儲和操作Modle）。一旦Model對象發(fā)生了變化（并不是真正發(fā)生了變化，而是產(chǎn)生了一個新的Model），Redux就會通知React Component根據(jù)新獲得的Model去重新Render。
顯然，React扮演的是View的角色，Redux則是Controller，至于Model就是Redux Store中存儲的State。我們要從MVC模式的角度去思考React+Redux開發(fā)，把代碼需要做的每件事情想清楚，明確是誰的職責，如此才不至于在實現(xiàn)時走歪路，不討好地去編寫大量View的控制邏輯，尤其是那些牽涉到parent-child組件的遞歸關(guān)系時，可能會讓前端代碼燉成一鍋粥。
舉個實例。
我們要在前端編寫一個過濾器，UI展現(xiàn)與控制邏輯類似Logiform，如下圖所示：
這個過濾器可以理解為以Condition為根的一個遞歸嵌套樹形結(jié)構(gòu)，枝為Group，而葉為Expression。Group還可以嵌套Group或者Expression?？梢蕴砑?、刪除Group或Expression，也可以調(diào)整它們在樹中所處的位置。
針對這樣的需求，如果我們企圖在React Component中直接去操控和管理這些邏輯，就需要考慮Component的父子關(guān)系，還需要考慮添加或刪除Dom節(jié)點對整棵樹的影響。
如果我們站在前述MVC模式的角度來考慮過濾器樹的呈現(xiàn)與界面控制，其實不過就是針對Condition對象模型的操作罷了。這個時候，我們可以不用去操心DOM節(jié)點之間的關(guān)系，而是直接用React Component去render模型對象。對象的粗略結(jié)構(gòu)如下所示：
{
"id": 1,
"operator": "and",
"conditions": [
{
"id": 2,
"type": "expression",
"operator": "=",
"fieldId": "11000",
"value": 3
},
{
"id": 3,
"type": "group",
"operator": "or",
"conditions": [
{
"id": 4,
"type": "expression",
"operator": "<=",
"fieldId": "11001",
"value": 20
}
]
}]
}
由于render是一種只讀的操作，要在React Component中去render這樣的結(jié)構(gòu)是非常容易的。如上，當我們要刪除id為2的Expression時，其實就是去編寫一個reducer，將其轉(zhuǎn)換為如下的對象：
{
"id": 1,
"operator": "and",
"conditions": [
{
"id": 3,
"type": "group",
"operator": "or",
"conditions": [
{
"id": 4,
"type": "expression",
"operator": "<=",
"fieldId": "11001",
"value": 20
}
]
}]
}
render對UI的呈現(xiàn)與控制邏輯完全相同，并不需要再去控制復(fù)雜的DOM。
概況下來，React+Redux的主體流程為：
- 通過action獲得model，并將其作為state存儲到Store中；
- 傳遞給React Component，按照某種設(shè)計呈現(xiàn)model數(shù)據(jù)；
- 調(diào)用action發(fā)起update請求，從而調(diào)用reducer生成新的state存儲到Store中；
- redux通知React Component重新Render。
這是MVC三種角色各司其職相互協(xié)作的結(jié)果。
