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