Taro 3 正式版發佈：開放式跨端跨框架解決方案

做者：凹凸曼 - yuche

從 Taro 第一個版本發佈到如今，Taro 已經接受了來自於開源社區兩年多的考驗。今天咱們很高興地在黨的生日發佈 Taro 3（Taro Next）正式版，但願 Taro 將來的更多兩年能像一名共產主義戰士同樣經受住更多的考驗。如下是 Taro 3 的一些新增特性：

跨框架：React、Nerv、Vue 二、Vue 三、jQuery

在舊版本的 Taro，咱們以微信小程序的開發規範爲基準，使用 React/JSX 的方式來進行開發。而在 Taro 3，咱們把這一思路量化爲一個編程模型：

設微信小程序生命週期爲一個 interface，不一樣的框架實例的生命週期雖然不盡相同，但咱們能夠根據框架生命週期分別新建一個 class 去 implements 小程序生命週期的 interface。相應地，小程序的組件/API/路由規範可使用一樣的思路和模型讓不一樣框架的代碼，運行在不一樣的端上：

在 Taro 3 中咱們內置了 React、Nerv、Vue 二、Vue 3 四種框架的支持，開發者能夠經過 taro init 命令建立對應的模板，並編寫與框架自己生命週期、調用方法合乎一致的代碼（idiomatic code），在語法上也沒有任何的限制。

在四類框架以外，Taro 3 還提供 jQuery-like API 的支持，做爲現代開發框架的補充和實現跨框架組件的方案。

跨端：H五、微信、支付寶、百度、字節跳動...小程序

和舊版本的 Taro 同樣，Taro 3 支持編譯到微信、京東、支付寶、百度、字節跳動、QQ 等主流小程序平臺。

和小程序同樣，Taro 3 的 H5 端相較於以前版本的 Taro 是一次完全的重寫：基礎組件如今所有使用 Web Components 構建，路由系統也徹底與前端框架解耦，所以在 H5 端 Taro 也實現了跨框架。無論開發者使用的是 React、Vue 仍是 Nerv，均可以同時運行在各類小程序和 H5 上。

開放式插件系統

Taro 3 在編譯時引入了基於 Tapable 的插件系統，開發者能夠經過編寫插件的方式爲 Taro 拓展更多功能或者爲自身業務定製個性化功能。在運行時咱們則從 React Reconciler 中獲得啓發，在 Taro 運行時也實現了一套修改運行時邏輯的 API。

也就是說，開發者能夠在不修改甚至不瞭解 Taro 源碼和實現的狀況下經過 Taro 拓展更多端，拓展更多的框架。在下個 Minor 版本（v3.1.0）Taro 就會完成編譯時/運行時與端/框架的解耦，屆時開發者只要寫一個插件就能拓展新的端或框架。將來 Taro 添加新的端或框架也會經過這樣的方式進行。

開源治理與項目治理

爲了與開發者更高效地交流，Taro 從 Vue.js 和 Ant Design 獲得啓發，引入了 Issue Helper 工具。爲了讓 Taro 在重大特性更新和更改能穩步推動，咱們又從 Rust、React 中學習，引入了 RFC 流程機制。爲了讓版本迭代更透明、更規範，Taro 在從此版本發佈也會遵照 Milestone 機制。

文檔是開發者最好的朋友。在 Taro 3 咱們對文檔也進行了改版和從新梳理，並推出了新的 [漸進式文檔]()，漸進式文檔按照開發項目的順序介紹 Taro 的基礎概念和優化技巧，適合喜歡邊學邊作或對小程序開發沒有任何瞭解的開發者。

代碼質量和穩定性對開源項目很是重要。Taro 也在嚴格貫徹 Code Review 機制，全部人的代碼都要被審覈，沒有人例外。爲了保證咱們能更大膽地迭代新特性，在整個 Taro 3 開發期間咱們總共添加了三萬行測試代碼。

微信小程序轉 React/Vue

早在 Taro 1.2 發佈 時，咱們就提供微信小程序轉 Taro 的功能，轉換後的微信小程序應用會變成一個多端應用。如今這個功能也徹底兼容 Taro Next 的新架構，而且轉換後的代碼提供 React 和 Vue 兩種選項。和之前同樣，只須要在微信小程序項目根目錄執行命令 taro convert ：

$ taro convert

選擇想要轉換後的框架便可：

渲染 HTML 字符串

在小程序中渲染 HTML 字符串一般會使用 wxparse 這樣的第三方庫，但 wxparse 的 API 複雜，拓展性弱，內部實現不許確，最重要的是如今已經中止了維護。比起 wxparse，Taro 3 的 HTML 字符串渲染提供如下的特性：

• API 與 Web 保持一致，能夠直接經過 React 的 dangerouslySetInnerHTML 或 Vue 的 v-html 調用。
• 能夠經過 CSS 直接控制標籤樣式
• 給已經渲染的 HTML 標籤綁定事件
• 在 HTML 解析和渲染都提供了鉤子函數知足個性化渲染需求

你能夠訪問文檔渲染 HTML瞭解更多信息。

CSS-In-JS

在 React 社區有一個著名的 CSS-in-JS 解決方案: styled-components。但遺憾的是，styled-components 使用 <style> 標籤來動態地控制樣式，在小程序端沒有相似的方案。但在 Taro 中咱們能夠經過 linaria 實現一樣的功能，linaria 主要提供如下特性：

• 近似於 styled-components 的 API
• 完整的 TypeScript 支持
• 零運行時

其中零運行時對於打包體積有要求的小程序尤其重要。

你能夠訪問文檔使用 CSS-in-JS瞭解更多信息。

虛擬列表（VirtualList）

當咱們渲染數據量很是大的列表時，框架會根據數據嘗試全量渲染視圖，這就可能會產生性能問題致使視圖沒法響應操做一段時間。爲了解決這個問題，咱們能夠採用另外一種方式：比起全量渲染數據生成的視圖，能夠只渲染 當前可視區域(visable viewport) 的視圖，非可視區域的視圖在用戶滾動到可視區域再渲染：

| |
|:--:|
| 正常渲染和虛擬列表的區別 |

| |
|:--:|
| 在開發者工具的直觀效果 |

相似的技術在 Android 開發被稱之爲 RecyclerView，在 React Native 叫作 VirtualizedList，咱們統一命名爲虛擬列表（Virtual List），這個組件如今內置在 Taro 中，在 React/Vue 或各類小程序及 H5 皆可以使用：

import VirtualList from '@tarojs/components/virtual-list'

你能夠訪問文檔長列表渲染瞭解更多信息。

預渲染

初始化性能是 Taro 3 的性能優化的痛點。原生小程序或編譯型框架的初始數據能夠直接用於渲染，但 Taro 3 在初始化時會把框架的渲染數據轉化爲小程序的渲染數據，多了一次 setData 開銷。

爲了解決這個問題，Taro 從服務端渲染受到啓發，在 Taro CLI 將頁面初始化的狀態直接渲染爲無狀態的 wxml，在框架和業務邏輯運行以前執行渲染流程。咱們將這一技術稱之爲預渲染（Prerender），通過 Prerender 的頁面初始渲染速度一般會和原生小程序一致甚至更快。

你能夠訪問文檔預渲染瞭解更多信息。

更快的構建速度和 source-map 支持

做爲一個編譯型框架，舊版本的 Taro 會進行大量的 AST 操做，這類操做顯著地拖慢了 Taro CLI 的編譯速度。而在 Taro 3 中不會操做任何開發者代碼的 AST，所以編譯速度獲得了大幅的提升。

正由於 AST 操做的取消，Taro 也輕鬆地實現了 source-map 的支持。這對於開發體驗是一個巨大的提高：

沒有槍，沒有炮，沒有輪子本身造

把時間節點再跳轉回兩年前，市面上並無一個支持使用 React 開發小程序的框架，也沒有什麼思路或探索能提供指引，咱們面對的狀況和舊中國「一貧如洗」的狀況差很少。今天，Taro 已是中國活躍度 Top 5 的開源項目。

辦法老是比困難多，即使是在小程序這樣相對受限的開發環境。從此，Taro 依然會從開發者的角度出發，不斷完善開發體驗，提高開發效率，走中國特點發展道路，遇山開山，遇水搭橋，努力成爲小程序開發，甚至多端開發的基礎技術設施——Taro 3 就是實現這一願景最堅實的一步，正如一位智者所言：

上車 Taro 最好的時機是從前，其次是如今。

---

歡迎關注凹凸實驗室博客：aotu.io

或者關注凹凸實驗室公衆號（AOTULabs），不定時推送文章。