Rax App 研發框架背後的思考

前言

Rax 答疑羣常常會有相似這樣的問題：」個人 rax 版本是 1.1.4，想要使用小程序原生組件應該怎麼作？「，從這個問題不難看出，站在使用者的視角來看，Rax 發展到今天已經再也不只有類 React DSL 驅動多端渲染這一單點特性，而是更加多元化的跨端解決方案，是更加立體的：DSL + 研發框架 + 輔助工具 + 平臺。前端

通常來講，咱們回覆的第一句是：「你用的什麼工程？能夠看下 build.json 麼？」因此不難看出，目前 Rax 所提供的多端解決方案是和工程、研發框架密切相關的。react

筆者從畢業到如今也參與過一些 Rax 多端相關的事情，包括淘寶小程序、Rax 轉小程序、Rax App 研發框架等等。寫這篇文章的目的其一是今年前端委員會跨端專項的部分紅果總結、其二是但願可讓你們進一步瞭解 Rax 跨端框架在實現多端一致性的過程當中經歷了什麼事情以及背後的思考與選擇。webpack

Rax App 研發框架

站在開發者視角，直接和他們打交道的就是 Rax App 研發框架。那麼，Rax App 研發框架是什麼呢？1. Rax App 提供了構建多端產物的能力，這也是開發者最本質的訴求；2. Rax App 提供了開箱即用的構建配置能力；3. Rax App 提供了項目開發的最佳實踐；4. Rax App 會適配不一樣容器，儘量提供多端一致的表現。git

更爲重要的是，和市面上不少多端方案不一樣的是，Rax App 並不會特別傾向於某一個容器的能力打造，咱們的目標是可以讓支持的全部容器性能表現和使用體驗上都達到業界第一。github

漸進式 React DSL 背後的思考

Rax App 自己是離不開 Rax DSL 的，站在當下的視角來看，Driver 的設計依然是先進的。哪怕是後來的 react-reconciler 其實均可以看到 Rax Driver 的影子。多端渲染的本質是渲染器的能力、繪製視圖的 API，因此經過 Driver 能夠很好的經過 VDOM 將業務邏輯自己和容器繪製能力解耦。web

JSX 自己帶來的是 React 豐富的社區生態以及業務使用的易用性、符合直覺的開發方式。進一步的爲了簡化部分場景業務使用的複雜度，Rax 提供了 JSX+ 的寫法，能夠經過 x-if 這樣指令輕鬆完成條件渲染。但目前這樣的寫法對 TypeScript 支持還不太好，在即將發佈的 TS 4.2 將會解決這個問題。json

將來，Rax DSL 在和 React DSL 儘可能保持用法一致亦或是子集的狀況下，會有更多符合無線業務場景的判斷與選擇。小程序

工程與多端解決方案

能力簡介

Rax App 目前支持構建 Web/小程序/Kraken/Weex 產物，在 Web 上提供了包括 PHA、SSR 等多樣的性能提高方案，小程序上提供了編譯時、運行時雙引擎方案，同時 Native 側支持 Kraken、Weex。緩存

小程序

小程序的能力，是前端委員會跨端專項中比較重要的一部分，在過去的 S1，Rax 自己着力提高了運行時方案的性能，而且提供了開箱即用的雙引擎混用方案。babel

方案實現本文再也不贅述，能夠看如下文章：

筆者更多要介紹的是，在實現這些方案過程當中，咱們的思考是什麼？以及遇到了什麼問題，怎麼解決的。

UI 資源引用

在 Rax 小程序的方案中，咱們支持了運行時項目中使用原生小程序組件、Rax 編譯時組件、原生小程序頁面、小程序插件等能力，在編譯時項目中支持使用原生小程序組件、插件、頁面。

豐富的組合能力背後咱們須要考慮的是，IDE 響應速度、用戶體感使用速度、使用一致性等等。經過避免 json 配置文件重複寫入大幅提高了 IDE 熱更新響應速度。經過拷貝 package.json，自動安裝依賴避免了因爲支付寶構建限制致使的冗餘安裝流程。經過 AST 分析，自動尋找原生 DSL 寫法幫助開發者能夠直接經過 import Buttom from '../miniapp-native/Button/index' 寫法引用組件。

雙引擎混用與分包加載

在雙引擎混合和分包加載的背後，除了工程構建以外，咱們奉行『約定大於配置』的準則。好比在 miniapp-compiled 下放置經過 JSX 寫的編譯時組件；分包模式下 src/pages 下面的一級目錄都是獨立分包，同時還能構建出幾乎一樣表現的 Web 產物。

除了以上所說的以外，Rax 小程序工程上還作了不少不少的事情，咱們真的很重視，業務方提出每一條關於使用體驗、構建能力上的訴求，在這個龐大的體系之下，咱們更但願能和開發 Web 同樣開發小程序，尋求當下咱們能想到的最優解。在業務紛雜的今天沒有十全十美的方案，只有在不斷權衡、取捨咱們推薦的最佳實踐。

Web

無線 Web 頁面，也是截止目前 Rax 深耕最久的領域，咱們提供了比React 更快的 SSR 方案，和 WebView 結合的 PHA 方案：經過框架能力提供相似多頁 TabBar、橫滑、緩存、Prefetch、同層渲染組件等能力，以及比較基礎的快照、保活能力。

配置簡化

搞前端最討厭的事情之一就是配 webpack，得益於 build scripts 拉通了集團的前端工程構建體系。因此，Rax App 能夠輕鬆進行相似以下配置：

alias

{
  "alias": {
    "@components": "src/componentns"
  }
}
複製代碼

minify

{
  "minify": false
}
複製代碼

babelPlugins

{
	"babelPlugins": ["babel-plugin-import"]
}
複製代碼

更多的使用能夠看這篇文檔。筆者所想表達的是，經常使用的構建配置 Rax App 幾乎都有考慮到，你能夠不用在乎背後的實現，就輕鬆達到業務想實現的構建效果。

運行時體驗一致性

筆者在這一節將以生命週期爲例進行展開。

若是你們接觸 React 多的話，可能對 componentWillMount、componentDidMount 這些組件的實例的生命週期比較熟悉。完整的生命週期，更多的指的是什麼？更多指的是一個應用的生命週期。

完整的生命週期能夠作哪些事情？

埋點：好比說在頁面切換過來的時候，我須要上報一個曝光埋點。
監控：好比說一些頁面報錯怎麼收集，假設咱們有本身的監控系統，怎麼去看咱們線上業務存在哪些問題。
響應式的交互：好比從 a 頁面切到 b 頁面，假如 b 頁面去作了相似登錄的操做，再返回到 a 頁面的時候，咱們須要有個 a 頁面的生命週期來實現例如權限的一些視圖變化，或是狀態的切換等等。咱們團隊如今是提供了一套面向多終端框架的解決方案，但願可讓用戶在開發中後臺、PC、無線等多端應用時的開發體驗是一致的，這樣能夠減小開發團隊成員的上手成本。
清理定時器：避免一些內存泄漏或者不必的事件回調。
獲取啓動參數：好比說在小程序裏面，須要在應用啓動階段，如 onLaunch 階段去獲取一些啓動參數等等。

因此基於上面這些需求，以及業務上的真實痛點，咱們作了多端體驗一致的生命週期，主要分爲兩部分：

App 的生命週期：包括應用的啓動 onLaunch 事件，應用的報錯 onError 事件，應用的 onShow 事件，應用的 onHide 事件。將來咱們可能會加入針對 TabBar 點擊的事件，如在點擊 TabBar 時，須要作一些曝光埋點的能力，會針對 TabBar 的操做暴露出相關的生命週期。
頁面的生命週期：usePageShow 、usePageHide 等 Hooks，onShow，onHide 等事件。

這裏有同窗會問說爲何 usePageShow 、usePageHide 這裏稱爲 Hooks，而 onShow，onHide 稱爲事件。這是由於在社區解決方案裏面我常看到的 useXXX，不少其實就是 API 的調用，並非真正的 Hooks，也就是說這種 API 的調用方式跟 Hooks 自己並無關係。咱們這裏的 usePageShow 是真正的 Hooks，它跟 onShow 不一樣之處在於，usePageShow 的觸發時機是在組件渲染完成以後，而 onShow 是在組件示例初始化的時候，也就是頁面剛進來的時候，就會觸發這個 onShow 事件。

不管是在 Weex，仍是在 Kraken ，仍是在小程序，或是在 Web 等等業務形態上，咱們的方案表現都是徹底一致的，包括觸發時機和觸發順序，這樣可以讓你的業務邏輯在開發時保持徹底一致。usePageShow 是在組件渲染完成以後，onShow 是在組件實例化的時候，也就是頁面剛進入時。

總結：Rax 跨端框架的展望

Rax 的願景，基於前端生態打通多端體系。在跨端體系的建設過程當中，研發框架須要既要扮演構建器的角色，還要扮演拉平體驗一致性的角色。將來，咱們會經過 Rax App 研發框架提供更多的最佳實踐，例如監控、埋點、數據請求等等，同時也會保持儘量保持克制、穩定性，框架自身測試覆蓋率、保證最後生成的 bundle 只包含用戶須要的代碼、探索新的方案提高構建速度等等。

最後筆者想說的是，Rax 的成長、發展離不開全部業務方的支持，感謝大家選擇 Rax，同時感謝可能平時答疑被咱們不當心冷落或者沒顧及到考慮的同窗，有大家真好，有大家 Rax 會更好。