作者 | 馬靖

出處:

https://mp.weixin.qq.com/s?__biz=MzUxOTE5MTY4MQ==&mid=2247485570&idx=1&sn=2d50271562368dbcbf7d6da0f0bcdcda

day day up, bye bye bug

鏘鏘鏘～ 小夥伴們，新出的會議室預約系統用著還順手嗎？快告訴我，對比之前的古老預定方式是不是方便很多？系統響應快不快？介面是不是一目瞭然？互動方式友好嗎？

看著每天預約人數這麼多，無疑答案都是肯定的。

那你有沒有預約個會議室來把玩一下？預約網紅會議室像不像淘寶雙十一的大搶購？悄悄告訴你，會議室預約系統採用的前端框架，就是淘寶雙十一的 Rax。愛學習的你一定嗅到了知識的味道～

那什麼是 Rax，怎麼用 Rax，什麼時候用 Rax 呢？接下來，前端女同學就來聊聊會議室預約系統的前端技術使用。

1. What

什麼是 Rax 呢？來看官方定義

Rax 是用於構建通用應用程式的漸進式 React 框架，其內部提供基礎UI元件。目前，在阿里系公司展開使用，並在淘寶雙十一購物節中獨領風騷。

透過上面定義我們知道，Rax 是基於 React 標準，並支援在不同容器中渲染（當前最重要的容器即 Weex 和 Web ）。

核心思想兩個 “ React ” 標準和 “ 跨容器 ”。別問為什麼，先記住，快，我知道你要問什麼；因為接下來我要講 Rax 和 React 的關係了，聽完你就沒有疑惑了。

1.1 Rax 和 React

我們可以把 React 看作是一種標準，那麼Rax 就是對該標準的一個跨容器框架的實現。也可以說 Rax 只是 React 的無線端的解決方案，與 React 並無衝突，我們就把 Rax 看作是一種擴充套件，因為 Rax 與 React 還是有一定的區別。

比如：Rax 沒有 createClass() 方法；Rax 可以返回多個同級結點，React 只能有一個結點；React 中的生命週期在 Rax 也同樣可用，一些副作用和鉤子函式均可使用。說到這些，你一定會想到 state，認為 state 狀態的設計一定也一樣，其實暗藏玄機（故意神秘）。

1.2 setState 不同

常言道： 結論先行，來，上結論。setState(updater, callback) 在 React 中是非同步/同步的，而在 Rax 中是同步的。

先一起回顧一下 React 中怎麼處理 setState 問題。

1.2.1 React 的 setState 機制

在 React 中，setState 後通常會集齊一批需要更新的元件，然後一次性更新來保證渲染的效能。

這也是通常操作，React 裡面有兩個更新 state 的方式，同步和非同步。如果是由 React 事件引發的 setState（如 onClick 和鉤子函式)，呼叫 setState 是非同步更新，除此之外的 setState 是同步執行（如 addEventListener 和定時器等）

React 會把每一次的 setState 操作放入一個佇列裡面，會先判斷是否由 React 事件引發的 setState ，來判斷是直接更新還是批次更新。

先對 React 事件進行標記，將 setState 傳入的 state 引數儲存在當前元件例項的 _pendingStateQueue 中；將 React 事件引發的 setState 更新放入非同步佇列中並 dirty 標記，需要批次更新 state，把 VDom 到 Dom 的操作降到最小；非 React 事件引發的 setState ，進行同步執行直接更新；1.2.2 Rax 的 setState 機制

Rax 的 setState 為同步更新。只要呼叫 setState 就會直接更新對應的狀態。

然而 setState 是會引起檢視的更新會引發重繪。也就是會重新走一遍更新階段的生命週期，這樣一來勢必會帶來效能問題，這時候就需要開發者需要控制好更新時機，要不然系統就會卡卡卡卡卡卡。也是正因如此，Rax 對開發者的要求略高。

1.3 Rax 特點設計上支援不同容器；Rax 在設計上儘量抹平各個端的差異性，這也使得開發者在開發中，差異性和相容性方面再也不需要投入太多精力。體積足夠小；Rax 是一個面向無線端的解決方案，因此自身的體積對於效能來講就顯得非常重要。Rax 壓縮 + gzip 後的體積是 8.0kb, 相比 React 的體積, 對於無線端很友好。支援返回多個同級節點；這一特性可以有效減少頁面的巢狀層級，從而減少應用因巢狀層級過多而出現的 crash 問題。標準化；需要適配各個端，那麼需要各個端的一致性，一致則必有規範可依，目前 Rax 遵循 W3C 標準，受限於各個端的差異，「更標準化」這也是 Rax 未來的重要目標之一。1.4 多端執行機制

來，先上圖

Rax 的跨容器特性是透過抽象出 View 層來實現的。

Rax 將 Vdom 與 Dom之間的轉化抽象出 Driver，依靠 Driver 來驅動實現跨端。

Driver 定義了 VDOM 在具體容器下的渲染實現。比如在 Web 場景下，對應的 Driver 為 Driver-Dom，它描述了在瀏覽器中，如何將 VDOM 渲染為真實的 DOM。

正是基於這種思路，同一套程式碼，經過不同的 Driver 就可以執行在不同的容器下。

2. How2.1 建立

快速建立一個 Rax 多端應用

 npm init rax todoList

2.2 初始化

初始化專案過程中， 按照專案的需要選擇配置資訊。以下是簡單 todolist 的 demo 演示所需要的配置項。

2.3 專案目錄

初始化的專案後，得到如下專案結構

├── README.md                   # 專案說明├── build.json                  # 專案構建配置├── package.json└── src                         # 原始碼目錄    ├── app.js                  # 應用入口檔案    ├── app.json                # 應用配置，包括路由配置，小程式 window 配置等    ├── public                  # (可選)靜態資源目錄，會複製內容至 build 目錄    ├── components              # 應用的公共元件    │   └── Logo                # 元件    │       ├── index.css       # Logo 元件的樣式檔案    │       └── index.jsx       # Logo 元件 JSX 原始碼    ├── document                # 頁面的 HTML 模板    │   └── index.jsx                   └── pages                   # 頁面        └── Home                # home 頁面            └── index.jsx    

2.4 路由配置

Rax 使用 rax-use-router 來管理多個頁面，生成的 Rax App 是一個單頁應用（可透過 build-plugin-rax-multi-pages 切換成多頁應用）

配置：路由的配置如同小程式的配置，在 app.json 中直接寫入；使用：路由正常使用，動態路由和路由對引數，不能直接從 props.id 獲取，路由資訊需要自己解析，不能像 react-router 那樣。路由的配置資訊如下圖所示。

2.5 狀態管理

狀態管理方面可以採用和 React 相同的狀態管理庫，大致分為兩類：

第一類：搭配中介軟體 Redux 狀態管理，為了簡化開發關注點，對 Redux 進一步封裝，例如：Dva 等等；

第二類：採用 observerble 的方案，例如：MobX 等；

如果使用狀態管理的業務場景較少，可以考慮 React 的 Context ，官網推薦的 hooks 中 useContext + useReducer 搭配使用。具體的使用方案還是要看具體的業務需求。

2.6 元件傳參

父 => 子：父元件可以透過 props 給子元件傳遞資料；

子 => 父：子元件可以透過 callBack 的方式呼叫父元件；

兄 <=> 弟：對於兄弟元件或者跨層元件，可以透過發事件的方式通訊，也可以單獨引入狀態管理框架來處理。

當然了，也可以拿到元件的例項，使用 ref 直接呼叫相應的方法。

2.7 UI 元件庫

Rax 的社群不夠活躍，幾乎沒有可用的第三方 UI 元件庫，僅有官方提供的一些常用功能元件，三大類元件庫如下：

基礎元件：如 View 檢視元件，預設 Flexbox 佈局，可任意巢狀；基礎容器：如 ScrollView 滾動容器，設定確定的高度展示列表內容；功能元件：Embed 內嵌內容容器，在 Weex 容器中透過 <web> 實現，在 Web 容器中透過 <iframe><embed> 實現；2.8 打包在 build.json 中選擇一個或多個需要投放的端，目前可供選擇的有 Web、 Weex、Alibaba Miniapp、WeChat MiniProgram、Kraken (Flutter)；執行 npm run build 命令即可按需生成 build 打包檔案。2.9 踩坑

（1）多利用 PureComponent，StatelessComponent 最佳化元件渲染

Rax 把很多處理效能最佳化的工作交給了開發者來處理，這也是 Rax 對開發人員要求更高的一個原因。PureComponent 在更新觸發時會比較 props 和 state，如果沒變化就不更新。StatelessComponent 在元件渲染時不會生成 Component 例項，能減少一定效能開銷；

（2）儘量控制好 Dom 的更新時機；

Rax 的 setState 是同步的，肯定需要避免頻繁呼叫，最好是資料都統一更新，自己手動呼叫 forceUpdate 更新 Dom；

（3）子元件適當提供 Key，儘量保持元件 Dom 結構的穩定；

子元件設定 Key 和 Vue 原理類似的，為了保持 Dom 結構穩定，當然也有利於虛擬 Dom 的 Diff 演算法，可以避免頻繁的 Dom 操作；

（4）Rax 中頁面寬度預設是 750rem，無單位可與 rem 單位等價替換，各端相容；

（5）路由傳參，不支援 props.id 直接獲取，路由資訊需要自己解析；

3. When

Rax 優點：跨容器、高效能、輕量。

但是 Rax 本質上還只是屬於 UI 層模式，在接入時應該注意和自己的底層框架解耦。並且 Rax 對開發者的要求較搞，如果沒有一定的經驗和規範約束，容易導致專案臃腫、結構混亂的問題。

目前在移動端 React 和 Vue 都有很高的佔比，社群生態也都比較活躍。具體的選型可以結合團隊的實際情況。

無論選擇哪個框架，都需要認真研究框架原理，對框架的優缺點和潛在問題做到心裡有數，如果能夠掌握其執行機制就更棒了，這樣在應對一些複雜需求和重大變化時才能遊刃有餘。

作者 | 馬靖

出處:

https://mp.weixin.qq.com/s?__biz=MzUxOTE5MTY4MQ==&mid=2247485570&idx=1&sn=2d50271562368dbcbf7d6da0f0bcdcda