簡聊前端中的 React.js

時間 2019-11-05

標籤前端 react.js react 欄目 React 简体版

原文原文鏈接

原文貼在公司網站上, 半個月前發佈的, 原文沒有強制換行. 在這邊備份一遍加上換行.
https://www.teambition.com/en...
更多關於 React 的消息能夠看 React 中文社區導航頁面:
http://nav.react-china.org
查找 React 中文文檔請往 https://doc.react-china.org/css

太早的事情須要看微博和 Git commits 記錄才能知道了.
去年一月份我接觸到過 React, 當時我關注的技術是 Ractive.
也是我快要到 Teambition 的時間, 簡聊(https://jianliao.com/)也恰好是那時候開始的.
後來我關注的技術是 Vue, 直到 5 月份開始轉投 React, 由於語法障礙克服了.
大體也就是如今簡聊用 CoffeeScript 寫 React 的緣由.
用了 10 月中旬側邊欄引入了 React, 今年 1 月中旬去掉了 Backbone 依賴.html

用這篇文章梳理一下, 目前簡聊在 React 方面的進展, 以及有待研究的方面.前端

簡述, 進展, 方向

進展

React 在 Teambition 的使用範圍限制在簡聊這個單頁面應用以內.
目前應用自己對 jQuery 依賴已經移除, DOM 操做也在以前全從 jQuery 遷移.
簡聊代碼中建立了 20 個左右公用組件, 大約 120 個其餘的組件.html5

部分較通用的代碼, 計劃拆分爲模塊在 GitHub 託管, 以及進行後續維護,
實際感覺單頁面的組件綁定業務邏輯會比較多, 所以通用性也有折扣.react

https://github.com/teambition...
https://github.com/teambition...
https://github.com/teambition... (試驗性)
https://github.com/teambition...jquery

此前簡聊代碼使用的是 Backbone, 所以上面的對比基於 Backbone.
組件化, 界面的可維護性, 路由, DOM 操做的效率, 都提高得很好.
好比消息流以前加載很慢, 可是改爲 React 之間自動合併了批量操做, 性能提高很明顯.
View 部分是咱們投入時間較多的部分, 功能也抓得比較緊.
React 對組件化的幫助很是大, 拆分模塊很是方便, 所以簡聊模塊才特別多.
我也努力在讓組件的通用性變得更強, 效果相對此前的 Backbone 也算滿意.
另外 react-router 也很好得知足了咱們的須要webpack

我我的認爲 jQuery 對 MVC 存在誤導, 建議儘可能避免手動的 DOM 操做.
Angular 跟 React 都是在 DOM 操做層面創建起更高級的抽象,
這個區別相似彙編語言的 goto label 結構跟高級語言的 for while 甚至 map reduce 方法的區別,
也就是對低級操做的細節進行封裝.git

須要跟進

React 的數據層方案不夠成熟, 實際上目前咱們的數據層也極爲簡單.
僅僅是 JSON 保存的數據, 參考官方 Flux 寫的簡單的 store.
面臨的問題是性能優化不夠, 穩健性也沒有好的方案保證.
初步想法是引入 immutable-js, 目前只是局部模塊使用, 還須要改進.
並且 Flux 的問題須要更多的經驗深刻考慮一下才行, 比較重要.
相對 Backone 來講, 方案更靈活, 但業務邏輯相對不夠清晰, 各有利弊.github

服務端渲染對前端來講, 主要頁面初次加載複雜的 API 請求邏輯不夠清晰.
其次是加載速度.. 不過加載速度是服務端渲染一作立刻就能改觀的事情.
除了初次加載問題, 切換路由時的數據加載, 也是先後端共用代碼的難點.
React 提供了機會能夠嘗試 Isomorphic JavaScript 應用, 深刻到數據路由界面所有代碼共用.
目前還在收集資料階段, 沒有深刻研究, 理想的目標是能幫助到公司其餘的頁面構建.web

React 當中跨組件共享狀態有難點, 並且排斥使用全局事件干擾數據流.
我相信這種限制是代碼穩定可靠的一個手段, 但也會增長開發的難度.
有時我在設想可否借鑑 Om 之類方案, 用全局數據更好地管理狀態?
由於在邏輯當中存在的多樣的狀態交換, 實在是須要想辦法支持的.
這個方面沒有很清晰的進展, 須要投入時間去摸索.

類庫使用

目前開發環境代碼優化後體積超過 1M, 採用 Webpack 進行了分包:

480K  js/main.59ad3c68fa5199b1268f.js
812K  js/vendor.7127c2f31156396dd4e9.js
172K  css/main.59ad3c68fa5199b1268f.css

具體到類庫方面首先是框架功能上必需的一些:

react(132k)
flux
moment(36k)
emojitfy.js
xss
favico.js
react-router
sockjs-client
spiderjs

大模塊:

jquery(計劃棄用) 84k
webuploader 71k(html5 52k)
https://github.com/mailru/Fil... 43k(html5 34k)
https://code.teambition.com/p...
immutablejs https://github.com/facebook/i... 56k
lodash 50k

小模塊:

全局事件 https://github.com/Wolfy87/Ev...
selection 處理 https://github.com/timdown/ra...
Ajax 請求 https://github.com/ded/Reqwest
className 拼接 https://github.com/JedWatson/...
瀏覽器檢測 https://github.com/ded/bowser
文件大小格式化 https://github.com/avoidwork/...
pen https://github.com/teambition...
pdfobject https://github.com/teambition...
thenjs https://github.com/teambition... 4.4k

CSS 模塊

CSS 部分一個是圖標字體的使用, 目前在公司統一的 UI 庫當中.
也有 Bootstrap 的依賴, 而我一直在嘗試弱化 Bootstrap 的部分.
目前只是部分引入, 但願之後有機會去除絕大部分 Bootstrap CSS.
Flexbox 是近期引入的, 爲了提高代碼質量開發效率, 放鬆兼容性, 有利有弊.

tb-ui
Bootstrap
flex.less(Flexbox LESS mixin)

前端技術

React 部分

簡聊總體創建在 React 跟 Webpack 上, 開發過程當中一些資料放到了 SF.
這些我在社區交流比較多, 若是咱們有更多時間整理技術, 會多作些交流.
由於我採用 CoffeeScript 書寫 JSX, 跟社區不少可能理解有差異.

React http://segmentfault.com/t/rea...
Webpack http://segmentfault.com/t/web...

React-Hot-Replace 支持的熱替換相比整頁刷新方便了不少, 但也存在不足.
項目代碼太多, 代碼保存 2s 左右頁面才能完成更新,
調試樣式實時性不夠, 甚至上線編譯整個項目的時間也超過 40s.
js 報錯的狀況下, 依然須要手動刷新頁面. 某些文件更改會致使頁面整個刷新.
編譯代碼通過文件合併, 不如獨立文件調試來得方便.

CSS

樣式代碼採用 LESS 爲主, 我但願部分代碼仍是以 CSS 存在, 好比組件能夠方面其餘項目複用.
具體樣式都參考 SMACSS 來進行規劃, 效果比較好:

SMACSS https://smacss.com/

另外隨着 Flexbox 使用, 界面的結構化和代碼的組件化會更輕鬆一些.
不過這個不是短時間能搞定的, 並且具體兼容性還要花時間對付一下.

CSS 繼承的問題是老大難, 很是難辦, 繼承徹底不夠在編寫應用當中使用.
CSS 選擇器極容易穿透組件做用到內層嵌套的組件當中.
單頁面應用當中大量嵌套組件是很是常見的, 因此這明確是 CSS 的問題.
本來 CSS 自己不該該做爲重點來應對, 但技術太不照顧單頁面的場景了.
Web Components 普及以前彷佛沒有很是好的辦法.

MV*

前端 MV* 模型的問題上, 基本上是 Flux, 並且還須要深刻探索.
因爲從 Backbone 轉過來, 實際上代碼用了大量的 listenTo 相似的實現.
嵌套太深, 因而內部的組件直接監聽 store, 也顯示出來 flux 在這方面不夠強大.
咱們沒有采用第三方的管理 Store 或者 State 的類庫, 而是官方基於 Demo 的手法改的: