Vite - React 組件開發實踐

去年發表的《一個好的組件應該是什麼樣的?》 一文介紹了藉助  TypeScript AST 語法樹解析,對 React 組件 Props 類型定義及註釋提取,自動生成組件對應 截圖、用法、參數說明、README、Demo 等。在社區中取得了比較好的反響,同時應用在團隊中也取得了較爲不錯的結果,現在內部組件系統中已經累計使用該方案沉澱 1000+ 的 React 組件。

之前我們是藉助了 webpack + TypeScript 做了一套用於開發 React 組件的腳手架套件,當開發者要組件開發時,即可直接使用腳手架初始化對應項目結構進行開發。

雖然主路徑上確實解決了組件開發中所遇到的組件無圖無真相、組件參數文檔缺失、組件用法文檔缺失、組件 Demo 缺失、組件無法索引、組件產物不規範等內部組件管理和沉澱上的問題,但 Webpack 的方案始終還是會讓組件開發多一層編譯,當一個組件庫沉澱超過 300+ 時,引入依賴不斷增長,還是會帶來組件編譯上的負荷導致開發者開發體驗下降。

一  Vite 帶來的曙光

Vite 給前端帶來的絕對是一次革命性的變化,這麼說毫不誇張。

或許應該說是 Vite 背後整合的 esbuild 、 Browser es modules、HMR、Pre-Bundling 等這些社區中關於 JS 編譯發展的先進工具和思路,在 Vite 這樣的整合推動下,給前端開發帶來了革命性變化。

我很早就說過,任何一個框架或者庫的出現最有價值的一定不是它的代碼本身,而是這些代碼背後所帶來的新思路、新啓發。所以我在寫文章的時候,也很注重能把我思考最後執行的整個過程講清楚。

Vite 爲什麼快,主要是 esbuild 進行 pre-bundles dependencies + 瀏覽器 native ESM 動態編譯,這裏我不做過多贅述,詳細參考:Vite: The Problems

在這個思路的背景下,回到我們組件開發的場景再看會發現以下幾個問題高度吻合:

那麼,以往像 StoryBook 和之前我們用於提取 tsx 組件類型定義的思路將可以做一個比較大的改變。

之前爲了獲取組件入參的類型數據會在 Wwebpack 層面做插件用於動態分析 export 的 tsx 組件,在該組件下動態加入一段 __docgenInfo 的靜態屬性變量,將從 AST 分析得到的類型數據和註釋信息注入進組件 JS Bundle,從而進一步處理爲動態參數設置:

TypeScript 對組件 Props 的定義

分析注入到 JS Bundle 中的內容

分析轉換後實現的參數交互設置

所以對於組件來說,實際上獲取這一份類型定義的元數據對於組件本身來說是冗餘的,不論這個組件中的這部分元數據有沒有被用到,都會在 Webpack 編譯過程中解析提取並注入到組件 Bundle 中,這顯然是很低效的。

在 Vite 的思路中,完全可以在使用到組件元數據時,再獲取其元數據信息,比如加載一個 React 組件爲:

import ReactComponent from './component1.tsx'

那麼加載其元數據即:

import ComponentTypeInfo from './component1.tsx.type.json'; 
// or 
const ComponentTypeInfoPromise = import('./component1.tsx.type.json');

通過 Vite 中 Rollup 的插件能力加載 .type.json 文件類型,從而做到對應組件元數據的解析。同時藉助 Rollup 本身對於編譯依賴收集和 HMR 的能力,做到組件類型變化的熱更新。

二  設計思路

以上是看到 Vite 的模塊加載思路,得到的一些靈感和啓發,從而做出的一個初步設想。

但如果真的要做這樣一個基於 Vite 的 React 、 Rax 組件開發套件,除了組件入參元數據的獲取以外,當然還有其他需要解決的問題,首當其衝的就是對於 .md 的文件解析。

1  組件 Usage

參照 dumi 及 Icework 所提供的組件開發思路,組件 Usage 完全可以以 Markdown 寫文檔的形式寫到任何一個 .md 文件中,由編譯器動態解析其中關於 jsx、tsx、css、scss、less 的代碼區塊,並且把它當做一段可執行的 script 編譯後,運行在頁面中。

這樣既是在寫文檔,又可以運行調試組件不同入參下組件表現情況,組件有多少中 Case,可以寫在不同的區塊中交由用戶自己選擇查看,這個設計思路真是讓人拍案叫絕!

最後,如果能結合上述提到 Vite 的 esbuild 動態加載和 HMR 能力,那麼整個組件開發體驗將會再一次得到質的飛躍。

所以針對 Markdown 文件需要做一個 Vite 插件來執行對 .md 的文件解析和加載,預期要實現的能力如下:

import { content, modules } from "./component1/README.md";
// content README.md 的原文內容
// modules 通過解析獲得的`jsx`,`tsx`,`css`,`scss`,`less` 運行模塊

預期設想效果,請點擊放大查看:

2  組件 Runtime

一個常規的組件庫目錄應該是什麼樣的?不論是在一個單獨的組件倉庫,還是在一個已有的業務項目中,其實組件的目錄結構大同小異,大致如下:

components
├── component1
│   ├── README.md 
│   ├── index.scss
│   └── index.tsx
├── component2
│   ├── README.md
│   ├── index.scss
│   └── index.tsx

在我們的設想中你可以在任意一個項目中啓動組件開發模式,在運行 vite-comp 之後就可以看到一個專門針對組件開發的界面,在上面已經幫你解析並渲染出來了在 README.md 中編寫的組件 Usage,以及在 index.tsx 定義的 interface,只需要訪問不同的文件路徑,即可查看對應組件的表現形態。

同時,最後可以幫你可以將這個界面上的全部內容編譯打包,截圖發佈到 NPM 上,別人看到這個組件將會清晰看到其組件入參,用法,截圖等,甚至可以打開 Demo 地址,修改組件參數來查看組件不同狀態下的表現形態。

如果要實現這樣的效果,則需要一套組件運行的 Runtime 進行支持,這樣纔可以協調 React 組件、README.md、TypeScript 類型定義串聯成我們所需要的組件調試 + 文檔一體的組件開發頁面。

在這樣的 Runtime 中,同樣需要藉助 Vite 的模塊解析能力,將其 URL 爲 **//(README|).html 的請求,轉換爲一段可訪問的組件 Runtime Html 返回給瀏覽器,從而讓瀏覽器運行真正的組件開發頁面。

http://localhost:7000/components/component1/README.html
-> 
/components/component1/README.html 
->
/components/component1/README.md
-> 
Runtime Html

3  組件 Props Interface

正如我上述內容中講到的,如果利用 Vite 添加一個對 tsx 的組件 props interface 類型解析的能力,也可以做成獨立插件用於解析 .tsx.type.json 結尾的文件類型,通過 import 這種類型的文件,從而讓編譯器動態解析其 tsx 文件中所定義的 TypeScript 類型,並作爲模塊返回給前端消費。

其加載過程就可以當做是一個虛擬的模塊,可以理解爲你可以通過直接 import 一個虛擬的文件地址,獲取到對應的 React 組件元信息:

// React Component
import Component from './component1.tsx';
// React Component Props Interface
import ComponentTypeInfo from './component1.tsx.type.json';
// or
const ComponentTypeInfoPromise = import('./component1.tsx.type.json');

由於這種解析能力並不是藉助於 esbuild 進行,所以在轉換性能上無法和組件主流程編譯同步進行。

在請求到該文件類型時,需要考慮在 Vite 的 Serve 模式下,新開線程進行這部分內容編譯,由於整個過程是異步行爲,不會影響組件主流程渲染進度。當請求返回響應後,再用於渲染組件 Props 定義及側邊欄面板部分。

在熱更新過程中,同樣需要考慮到 tsx 文件修改範圍是否涉及到 TypeScript 類型的更改,如果發現修改導致類型變化時,再觸發 HMR 事件進行模塊更新。

三  組件 Build

以上都是在討論組件在 Vite 的 Serve 態(也就是開發態)下的情況,我們上文中大量藉助 Vite 利用瀏覽器 es module 的加載能力,從而做的一些開發態的動態加載能力的擴展。

但是 Vite 在組件最終 Build 過程中是沒有 Server 服務啓動,當然也不會有瀏覽器動態加載,所以爲了讓別人也可以看到我們開發的組件,能夠體驗我們開發時調試組件的樣子,就需要考慮爲該組件編譯產出一份可以被瀏覽器運行的 html。

所以在 Vite 插件開發過程中,是需要考慮在 Build 狀態下的編譯路徑的,如果是在 Build 狀態下,Vite 將使用 Rollup 的編譯能力,那麼就需要考慮手動提供所有組件的  rollup.input(entries)。

在插件編寫過程中,一定需要遵循 Rollup 所提供的插件加載生命週期,才能保證 Build 過程和 Serve 過程的模塊加載邏輯和編譯邏輯保持一致。

我一開始在實現的過程中,就是沒有了解透徹 Vite 和 Rollup 的關係,在模塊解析過程中依賴了大量 Vite 的 Server 提供的服務端中間件能力。導致在考慮到 Build 態時,才意識到其中的問題,最後幾乎重新寫了之前的加載邏輯。

四  總結

我姑且把這個方案(套件)稱之爲 vite-comp,其大致的構成就是由 Vite + 3 Vite Pugins 構成,每個插件相互不耦合,相互職責也不相同,也就是說你可以拿到任意一個 Vite 插件去做別的用途,後續會考慮單獨開源,分別是:

結合 Vite,已經實現了 Vite 模式下的 React、Rax 組件開發,它相比於之前使用 Webpack 做的組件開發,已經體現出了以下幾個大優勢:

預覽體驗:

啓動

Markdown 組件文檔毫秒級響應

TypeScript 類型識別

Vite 現在還是隻是剛剛起步,這種全新的編譯模式,已經給我帶來了非常多的開發態收益,結合 Vite 的玩法未來一定還會層出不窮,比如 Midway + lambda + Vite 的前端一體化方案也是看得讓人拍案叫絕,在這個欣欣向榮的前端大時代,相信不同前端產物都會和 Vite 結合出下一段傳奇故事。

我是一個熱愛生活的前端工程師!Yooh!

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/owJX7VwN9T9hEcp7TPseUA