這幾個月都在使用 DHH 今年新發(fā)布的 StimulusJS 框架來寫 Web 程序, 真的感覺很好, 感覺開發(fā)Web項目充滿了生產(chǎn)力, 而不像 AngularJS/React 前端框架, 看著技術(shù)吊炸天, 但是真正要寫項目的時候, 除了感覺到炫技和頭暈外, 反而把簡單的事情弄得越來越復(fù)雜.
如果說 CSS 是把樣式從 HTML 剝離的技術(shù), Stimulus 就是把 JS 從 HTML 剝離的技術(shù), 結(jié)合 Turbolinks 一起使用, 開發(fā)效率和用戶體驗都很棒.
Stimulus 的代碼一般長這樣:
<button
data-controller="user"
data-action="user.action">
Text
</button>
當(dāng)點擊按鈕的時候, Stimulus 會自動找到 user_controller.js 文件, 并調(diào)用 user_controller.js 中的 action 函數(shù).
Stimulus 利用元素的屬性, 在保證 JS 和 HTML 之間關(guān)聯(lián)性的同時最大程度的保持 HTML 文件的干凈, 并自動建立從 HTML 元素到 JS 函數(shù)的連接, 不用手動在 JS 文件中寫很多這種邏輯孤立的回調(diào)函數(shù) $("button").click(function(){${ ... }).
說 Stimulus 是生產(chǎn)力代表一點都不為過, 不過今天不詳細(xì)講解 Stimulus 的用法.
今天主要講怎么利用 Stimulus 優(yōu)雅的處理 AJAX 請求, 來構(gòu)建健壯可維護(hù)的 JavaScript 代碼.
舉個簡單的例子, 如果我們要實現(xiàn)上圖中這種上傳頭像后自動更新頁面中兩處頭像元素的功能, 我們一般會按照下圖這種 Rails SJR (Server-generated JavaScript Responses) 流程來處理:
- 首先在瀏覽器端, 觸發(fā) submit 按鈕后, 提交表單數(shù)據(jù)到服務(wù)器
- 服務(wù)器接受到請求后, 在 ruby 控制器中處理數(shù)據(jù), 然后返回數(shù)據(jù)
- Rails 會根據(jù) ruby 控制器中 format.js 的名字找到對應(yīng)的 *.js.erb JS 模板文件, 并根據(jù)返回數(shù)據(jù)生成最終的 JS 文件
- JS 文件隨著 AJAX 的結(jié)果返回給瀏覽器中執(zhí)行并更改HTML頁面的DOM結(jié)構(gòu)
如果我們用 Stimulus 技術(shù)來處理, 看看會有哪些變化?
- 首先我們會在 form_with 表單中增加 data-controller 和 data-action 字段, 表示 AJAX 成功返回結(jié)果后, 調(diào)用 user_controller.js 的 update 函數(shù), submit 按鈕點擊后提交表單數(shù)據(jù)沒什么變化
- 服務(wù)器的 ruby 控制器在處理數(shù)據(jù)后, 返回的并不是 JS 文件, 而是返回 JSON 數(shù)據(jù)
- Stimulus 的JS文件在接到 AJAX 返回的 JSON 數(shù)據(jù)后在瀏覽器端修改 HTML頁面的DOM結(jié)構(gòu)
其實從大的流程運(yùn)行和最終改變 HTML DOM 結(jié)構(gòu)的效果上, 并沒有產(chǎn)生太多不同.
但是從技術(shù)團(tuán)隊的開發(fā)和可維護(hù)上, 有 Stimulus 技術(shù)的輔助, JavaScript 代碼的可維護(hù)性獲得了極大的提升.
我們首先來看看下面兩張圖:
- 第一張是 SJR 技術(shù)根據(jù)AJAX請求的響應(yīng)方式, SJR 技術(shù)的 ruby 控制器總是返回 format.js 的JS模板文件, 就會導(dǎo)致每個請求都會創(chuàng)建一個又小又碎的 JS 文件
- 第二張是 SJR 結(jié)合 Stimulus 技術(shù)后的響應(yīng)方式, SJR & Stimulus 技術(shù)的 ruby 控制器只是返回 JSON 數(shù)據(jù), 并不需要根據(jù)每個請求創(chuàng)建一個新的 JS 文件
在小項目的時候, 優(yōu)勢看不出來, 但是一旦業(yè)務(wù)變得越來越復(fù)雜的時候, 這些碎小的 JS 文件就非常難以維護(hù), 主要是因為這些 JS 文件往往都是極小的JS片段, 當(dāng)需要修改的時候, 往往要結(jié)合 HTML 和 ruby 的代碼一起看, 難以理解. 再加上這些 JS 文件運(yùn)行環(huán)境的復(fù)雜, 在運(yùn)行時也非常難以調(diào)試.
Stimulus 的好處就是, 把每個 AJAX:success 的 action 對應(yīng)到 controller.js 的一個函數(shù)中, 不同類型的 AJAX 請求可以分類到不同 Stimulus 控制器中分類管理, 因為每個 Stimulus 控制器一般都是根據(jù)某一個功能內(nèi)聚形成的, 在上下文理解和運(yùn)行時調(diào)試上都要比數(shù)量巨多的碎 JS 文件更容易維護(hù).
關(guān)于JS前端框架的一些看法.
現(xiàn)代的前端開發(fā)人員太浮躁了, 大多數(shù)前端從業(yè)同學(xué)都自從技術(shù)是否足夠復(fù)雜和精致上來評價一個技術(shù)框架的好壞, 而不從業(yè)務(wù)導(dǎo)向和技術(shù)的適用度來評價. 互聯(lián)網(wǎng)這種 "越復(fù)雜的技術(shù)才是最好技術(shù)" 的思想真是太膚淺了.
Web并不是一個 JSON API + JS Client render 的場景, 因為大多數(shù)Web應(yīng)用并不是游戲和高交互的程序, 大多數(shù) Web 產(chǎn)品依然是以內(nèi)容為主, 交互輔助的場景.
我相信開發(fā)過桌面程序的同學(xué)都知道, 如果Web服務(wù)器只是提供 API, 何不用本地圖形庫開發(fā)了? 本地圖形庫渲染的速度要遠(yuǎn)遠(yuǎn)快于瀏覽器, 而且客戶端渲染的技術(shù)真的非常難以控制, 一旦 API 之間不兼容或者版本迭代的時候, 非常非常的麻煩.
反觀 DHH 做的 Rails, Turbolinks 還是今天介紹的 Stimulus, 單從一個模塊的技術(shù)復(fù)雜度和精致程度并不能和 AngularJS/React 這些相比, 但是 DHH 真的很懂面向業(yè)務(wù)和開發(fā)生產(chǎn)力來開發(fā)新的技術(shù), Rails + Turbolinks + Stimulus 給我的感覺就像活塞隊一樣, 雖然每個技術(shù)都不是最頂尖的, 但是每個技術(shù)的比例和復(fù)雜度都剛剛好, 相互互補(bǔ)默契的結(jié)合可以掀翻看似全明星的湖人隊. 甚至可以說是在滿足功能的前提下盡最大程度減少邏輯的復(fù)雜度, 這樣構(gòu)建相同功能的代碼越簡單, 后期的維護(hù)性和可擴(kuò)展性都會越好.
最后我想說的是, 技術(shù)一定面向業(yè)務(wù)場景, 最合適的才是最好的, 技術(shù)應(yīng)該為人服務(wù), 使用起來應(yīng)該直覺化和簡單易懂, 完成開發(fā)后去像 DHH 那樣享受生活, 而不是沉浸在技術(shù)的復(fù)雜度中自我陶醉.
