關於從 Backbone 轉向 React 的思考(部分過期)

這篇文章是我在遷移以前寫的, 如今簡聊(http://talk.ai)已經徹底切換到 React.
公司技術內容更新會貼在: http://weibo.com/teabot

---

原理

我以爲 React 是我目前接觸到的開發 Web 應用最好的一個方案.
我剛用熟 Backbone 時候在想模板引擎的做用, 怎樣把數據轉化成爲界面,
在數據給定的狀況下, 界面是徹底遵守數據改變的..
這個有點像數學裏, 自變量因變量, 中間就被一個函數關聯了,
更重要的, 其實數據咱們應該只存儲一份, 因變量根據函數計算出來就行了

回到應用上來, 數據定義好後, 界面就徹底是根據數據渲染了
在 Backbone 中, 咱們須要頻繁操做 DOM 來保證界面到達最新狀態,
甚至有時候, 由於 DOM 上保存的狀態和數據不一樣步, 致使 Model 計算出錯
這一切, 讓我不斷以爲寫應用時就不該該存在 DOM 操做

出於這些想法, 我開始學習了 Ractive, 而後是 Vue, 如今是 React.
React 的基本思路就是, 數據更新以後, 渲染完整的界面的狀態,
而 DOM 則根據新的狀態, 從原來的基礎上, 作最小的操做, 來保證性能和狀態

關於底層的細節, 代碼我沒看懂代碼, 搜索到的資料上對於這部分有描述:

React’s diff algorithm
http://calendar.perfplanet.com/2013/diff/

摘錄一些有意思的地方:

• 爲了簡化 DOM 算法複雜度, DOM 的 Diff 限制在層級同樣的節點
• 列表渲染的節點, 須要提供 key 屬性來區分出惟一性
• 對比到 Component 時, 整個 Component 不一樣直接替換, 不按 DOM 比較
• React 的事件代理是本身實現的(和 jQuery 有區別, 我寫應用遇到過)
• setState 方法能夠將 DOM 標記須要從新渲染. 細化這個操做能夠提高性能
• 能夠定製 Component 的 shouldComponentUpdate 方法自行判斷是否渲染, 提高性能

用戶

主要是 Facebook 在生產環境使用了 React, 所以給人感受是挺靠譜的

How is Facebook's React JavaScript library?
http://www.quora.com/React-JS-Library/How-is-Facebooks-React-JavaScrip...

Using React to speed up the Khan Academy question editor
http://benalpert.com/2013/06/09/using-react-to-speed-up-khan-academy.h...

Who is using Facebook React?
http://www.quora.com/React-JS-Library/Who-is-using-Facebook-React

搭配 CoffeeScript

我用 React 寫了兩個小應用, 感受 React 思路很是清晰,
對我來講比較重要有一點是語法支持, 原生的 JSX 語法其實很是不方便編輯.
可是在 CoffeeScript 裏, 語法就是很是簡單的縮進, 比 HTML 清晰多了.

另外一個有意思的 Component 的概念, 相似 Backbone 的 View, 但輕量多了
並且, 由於 React 使用數據表達的 DOM, 寫起來很是簡化,
以及其組合的方式, 結果是 Component 的劃分也很是明確和細化,
能夠看個人應用裏爲了組合 Component 怎樣劃分的:

https://github.com/jiyinyiyong/react-todolist/tree/master/coffee/view

還有一個是, 由於界面是根據 Model 自動渲染的, 而操做 Model 其實很簡單,
因而咱們就有大量的精力能夠騰出來對付 Model 以及 ViewModel 相似的概念,
得益於此, 我用 React 輕鬆完成了 infinite scrolling 的效果, 徹底不用寫 DOM 操做:

https://github.com/jiyinyiyong/osx-fonts-view/blob/master/coffee/main....

中型(大型?)項目關心的

個人我的項目不用 Backbone, 由於太臃腫了, 可是對公司的中型項目來講還算合適,
因爲我對於 React 的認同, 特別是 Facebook 用在生產環境, 因此完成關心大應用的場景

• 性能

聽說很高, 由於消耗的不是 DOM 操做的性能, 而是 JS 性能, JS 自己其實挺快的
我沒找到個靠譜的測試, 能夠補上..

• 複雜的 View

我實踐過的例子比較簡單, 大的項目 View 的組合很複雜, 以及複雜的交互,
首先, React 的架構很方便 View 的擴展, 相比 Backbone 更靈活,
React 的結構更像是後臺應用, 一個數據庫, 前面是靈活渲染各類的 View.
對此我仍是比較樂觀的.

和 Backbone 對比

Backbone to React
http://joelburget.com/backbone-to-react/

這哥們寫了一篇文章叫這個名字.. 不過看內容的好像不明確啊..
我說一下我如今的考慮的這些事情:

• 雙向綁定

React 其實不是雙向綁定, 僅僅是單向的從數據到視圖的渲染
問題是 Backbone 沒有...
我最近遇到的 DOM 和數據綁定的事情, 以爲大量的手動綁定太痛苦了

• 狀態切換

狀態問題比較大, 好比 Backbone 渲染 View, 先用模版, 後用 jQuery
結果是對同個元素的渲染其實有兩套方案在發揮做用..
這樣的重複確定會讓人累, 其次, jQuery 命令式的操做方式顯然是不友好的..

• 第三方的模塊集成

用了 React 後, 對 DOM 的容忍就沒那麼好了, 至少比 Backbone 要差好多
在 Backbone 裏, 強行把 jQuery 寫的組件插進來尚且能作到,
在 React 裏不用 jQuery, 因此已有的 jQuery 組件能不能直接用要從新思考了

• 對後端開發人員更友好

Backbone 渲染模版部分和服務端渲染很是類似, 可是到了複雜的消息就不對頭了
爲了 Backbone 的手法能 work, 要想盡辦法轉化爲 Event 的方式
而 React 從理解上就是每次數據更新渲染整個頁面, 沒有推薦第二種方式...
就像是原來的, 每一個操做刷新頁面的思路, 很是清晰,,,
考慮到先後端都是 JS, 這將給後端開發的人帶來方便

• HTML 中空白的問題

最近用的模板引擎沒有處理好 HTML 當中奇怪的空白, 致使出現意外的間隔
由於 React 是經過 Virtual DOM 轉化的, 這樣的空白就是不存在的
我花很多時間想把 Cirru 編譯到 JS 模版來解決這個問題, 而 React 原生沒就問題

• 模版語法

HTML 模版中咱們避免不了邏輯, 結果仍是會插入一些簡單的邏輯進去
更麻煩的是, 有時候不想插邏輯的結果就是用 jQuery 去實現這部分邏輯
即使拋開這些, HTML 寫多了, 上邊這個狀態那個狀態, 就變得難看懂了

React 的 DOM 是從 JS 的數據結構裏生成的, 所以沒有維護和編譯模版的麻煩,
不過也有人會說 JS 裏寫 DOM 會很難看, 由於... 反正就是很難看
的確, 當頁面變大以後, 究竟會有多複雜我目前不清楚, 須要深刻看

• 數據結果更加隨意

Backbone 裏有 Collection 做爲約束, 固然也提供了一些方便,
可是真實場景的應用將會比較複雜, Collection 共用數據就麻煩很多
最近碰到的例子, 多個 Collection 存在對應同個 User 的多份數據,
如每次都刷新, 從 id 生成界面, 不會有問題, 可是 Backbone 裏不方便這麼作

• 數據狀態之間的切換

Backbone 麻煩的地方, 在於咱們用 jQuery 的時候, 手動維護狀態切換
問題是, 可能有多種狀態的時候, 就須要有多個狀態之間切換的代碼
這樣的狀態維護, 不是一份代碼, 而不是狀態和狀態相乘的結果的代碼,
雖然一般界面就是兩個狀態, 但某種程度上也是重複了一次操做.

期待

我想說 React 真的解決了好多 Backbone 裏的問題...
若是要切換, 就要開始考慮 React 引入的新問題是哪些, 可否容忍或者減輕?
以及在大項目當中使用 React 的經驗我也以爲不足, 細節上並不能有定論
因此想找機會用 React 嘗試一下稍微大一點的項目, 驗證可用性

---

返回博客首頁: http://blog.tiye.me/