電商React遷移之路

1、沃爾瑪電商React遷移之路 技術(shù)創(chuàng)新 變革未來摘要在過去的一年之中，沃爾瑪全球電商成功將現(xiàn)有的前端框架從Backbone遷移到React/Redux的全新平臺上。案例主要闡述了在此過程中沃爾瑪搜索前端部門的架構(gòu)，流程設(shè)計，開發(fā)，和回顧當中的成功與失敗。項目背景 是沃爾瑪全球電商在美國的主體。Alexa排行23, 在全美電商流量第三高Search frontend小組負責里跟貨品搜索相關(guān)的頁面： /search, /browse, /autocomplete, /tire-finder 的桌面和移動的客戶端與服務(wù)器端。直接處理 約50%的客戶流量。項目特點優(yōu)先首屏 (Above the Fol

2、d)的渲染和互動并不復雜的界面互動，不多的頁面狀態(tài)轉(zhuǎn)換(非SPA)需要大量AB測試CDN友好 /高并發(fā)SEO友好需實時商品數(shù)據(jù)頁面狀態(tài)與URL GET 參數(shù)掛鉤親和力 (Accessibility)廣告之前的技術(shù)棧前端: Backbone.js + Marionette + Jquery + Underscore + Handlebar后端: Tomcat/Spring 3 + Handlebar流程: 傳統(tǒng)的git master/feature/epic/release branchHTTP 請求搜索引擎數(shù)據(jù)在Spring的商業(yè)邏輯層服務(wù)器端HandleBar輸出HTML客戶端Backbon

3、eJs把界面分解成不同的Backbone MVC 單位每個Backbone單位根據(jù)新出現(xiàn)的UI事件來更新相對的界面OneWalmart - 新的需求重新整合沃爾瑪各前端團隊(SamClub, George ASDA, Walmart Grocery)的資源。把不同產(chǎn)品邏輯實現(xiàn)合并進同一個代碼庫。減低未來研發(fā)成本。重構(gòu)?Code Refactoring?現(xiàn)有方案的不足責任歸咎其他小組也有自己偏好的框架在一個文檔里加入來自不同產(chǎn)品的邏輯會令代碼變得復雜，難讀，和跟產(chǎn)品邏輯過分捆綁 (tight coupling with tenant logic)太多commit造成混亂HandleBar 作為

4、UI 渲染模版引擎只提供最簡單的條件支持XHR返回HTML不是很有效率Backbone各單位可以互動Backbone 沒有防止在頁面層次上修改DOM (global DOM manipulation) 的方案。具體功能性需求如果我們要做一個新的輪子，它應該是什么樣子的呢？1.支持現(xiàn)存的功能：現(xiàn)有的界面內(nèi)容優(yōu)先ATF渲染 (1500ms) 和互動(2500ms)的時間移動閱覽器上加載網(wǎng)頁的速度容易被CDN緩存高性能，可以應付網(wǎng)上購物高峰期 (平常流量的10倍）容易做AB測試單位測試UI實時更新產(chǎn)品細節(jié)分析 (Analytics)具體功能性需求 （繼續(xù)）2. 滿足OneWalmart的要求代碼分享

5、最大化提供每個產(chǎn)品足夠的自由實現(xiàn)各自的UX，排版，互動盡量保護每個小組的工作不被其他組的改動影響最好是:干凈，有美感不負責，容易上手吸引程序員不易犯錯前端框架選擇不同框架的強處, 抽象角度, 和基因抽象層的厚度/控制反向 (inversion of control) 的強度 (彈性自由 vs 方便自動)采用框架的成本 (文件大小，學習難度，社區(qū)支持)Angular1: MVVM. 界面和客戶端數(shù)據(jù)互相捆綁Polymer: web component跟shadow DOM的模仿ExtJs: 宣告性的框架BackboneJs: DOM樹分拆成獨立又互相影響的moduleReact：函數(shù)程序單方向數(shù)

6、據(jù)流程UI邏輯每個部分都可看成單獨的純函數(shù) (Pure Component)干凈明確的入口(prop) 跟出口 (JSX)可根據(jù)輸入預測輸出 (deterministic)運行時不會影響程式其他部分Isomorphic: 可以從服務(wù)器端(nodejs)或 客戶端同一個函數(shù)邏輯來輸出HTMLReact: 可組合性Component是基本的組成部件。較上層的Component 為 下層Component組合而成。下層的Component ：通用，可配置，可再用，與商業(yè)要求無直接關(guān)系。上層的Component：有明確商業(yè)要求的功能，通過props把配置傳給下層。高可用度。保持Component的函數(shù)

7、性質(zhì)FormPriceRowLabelTextfieldValidationReact: 其他優(yōu)點和缺點 火熱的前端社區(qū)支持 JSX比Handlebar更加功能強大 更容易吸引灣區(qū)的前端人員 界面/事件處理/數(shù)據(jù) 之間低耦合。軟件工程角度上，可以把做一個UI component分給3，4個人同時進行。每人做自己擅長地部分。 跟以前Backbone截然不同的編程範式 排外性：Legacy code依然需要JQuery跟直接對DOM的操作 (ad, Recommendation) 較厚的抽象層 Virtual Dom 耗費挺多的memory跟CPU周期React Router保持UI 與URL 同

8、步保持頁面滾動位置更適合復雜狀態(tài)變動的單頁應用KISS (Keep it simple, stupid)Redux減少父 component對子component 的聯(lián)結(jié)減少local state的使用Component同時被父component和store影響GitHub模式把代碼庫分拆為30+個Repositories。每個repo管理一個或一系列相近功能的低級 React Component或功能組件 : header, drop down, 動畫等等。每個repo都像公共repo那樣, 有獨立的維護，更新，和審批批準commit的成員。Repo成員從各個前端小組選出。他們拿出部分工作時

9、間來維護保障低級邏輯在開發(fā)新的功能時，鼓勵依賴現(xiàn)有的repo。盡量不要重做輪子。用NPM來管理每個repo的版本和依賴。用語義化版本控制每個依賴所容許的版本 (1.3.4 vs *1.3.4 vs 1.3.4)在代碼里，用common.js來要求需要的依賴.滿足需求: CDNAkamai CDN默認用URL來當作網(wǎng)頁的Cache key。但很多其他因素影響用戶最終得到的HTML:Ab測試的cookie用戶session cookie用戶地點閱覽器種類把變化較頻繁的內(nèi)容用XHR裝載* 商品價錢，可供應情況滿足需求：首屏渲染性能在客戶端渲染 ATF太慢了用node.js / hapi來在服務(wù)器端里

10、Virtual DOM性能不過關(guān) (650ms)。把常用，參數(shù)不變的Component緩存在memoryEarly flush后端輸出HEADER下載CSS/字體/圖片后端輸出首屏 HTML前端建立首屏DOM樹等待下載完畢滿足需求：互動性能ATF 渲染后開始下載React lib。Virtual DOM在客戶端獲得頁面的狀態(tài)數(shù)據(jù)后重新生產(chǎn)整個界面的HTML。以此代替了服務(wù)器端產(chǎn)生的ATF HTML。首屏DOM樹建立下載reactInline頁面數(shù)據(jù)React控制DOM樹滿足需求: 單元測試函數(shù)程序設(shè)計令整個應用本質(zhì)上就是由很多小單元組成: Component / Connect / Dispa

11、tcher只要小單元符合純函數(shù)的性質(zhì)，我們就可以很容易地模擬它的輸入，測試它的輸出。采用了Airbnb 的 Enzyme 單元測試框架 （http:/airbnb.io/enzyme/）Example滿足需求: 多租戶支持兩種邏輯實現(xiàn)：可以共享的，和租戶獨占的CSS每個component會有一個可以共享的common.styl 然后每個租戶在tenants/下再加入自己獨有的Ui特色和對common.styl的修改。2. JSX / ComponentComponent是所有邏輯實現(xiàn)的合集。支持了每個租戶的所有功能。用component prop來啟用/禁用功能React 15.0 之前，Virtual DOM還不是很成熟的時候，大部分DOM元素都被加了一個data-react-id的屬性滿足需求: 整合不支持React的服務(wù)當網(wǎng)頁只有一部分已經(jīng)遷移到React上外來插入DOM的內(nèi)容: 廣告，個性化服務(wù) (Personalization)，自定義HTML跟網(wǎng)頁其他部分的溝通項目回顧: 得益之處減低應用復雜度，讓編程者的注意力聚焦到小單元里