如何封裝不被嫌棄的組件SDK
你在一家小互聯(lián)網(wǎng)公司做前端。最近公司發(fā)展勢頭不錯，已經(jīng)有了穩(wěn)定的商業(yè)模式。老板決定嘗試付費推廣。
馬上五一了，老板想策劃一個活動玩法。可是公司前端人力有限，不能每個業(yè)務(wù)都單獨開發(fā)活動。
于是老板找到了你，希望你封裝一個活動SDK組件供公司幾個業(yè)務(wù)接入。
你心里嘀咕：平時組件寫的倒是很多，也寫過公共組件，活動組件感覺就是帶業(yè)務(wù)邏輯的公共組件，應(yīng)該沒啥難度吧?
但是你心里沒底，怕自己封裝的組件SDK被接入的業(yè)務(wù)方嫌棄，就去請教公司最資深(發(fā)量最少)的前端老卡。
待說明來意，老卡深深啄了一口保溫杯里的菊花枸杞茶。
“這封裝組件SDK的門道啊，分為組件設(shè)計、開發(fā)、接入、上線，待我一一道來”。
組件設(shè)計好的組件設(shè)計需要做到「職責(zé)明確」。在設(shè)計階段需要與3個角色明確職責(zé)：
與提供數(shù)據(jù)的服務(wù)端明確職責(zé)
活動內(nèi)部需要的數(shù)據(jù)通常由服務(wù)端提供，此時需要明確字段的粒度。
比如：邀請新用戶得xxx元獎勵
xxx是變量，通常會作為一個字段。
那么「邀請新用戶得 元獎勵」這段文案呢?活動進程中，有沒有可能PM發(fā)現(xiàn)這段文案效果不好想修改。
如果前端寫死了文案，要修改意味著組件提供方(你)與業(yè)務(wù)接入方都有重新上線的成本。
所以，如果評估有修改的可能，更好的方式可能是將這段文案下發(fā)為類似結(jié)構(gòu)：
- data: {
- title: "邀請新用戶得{{bonus}}元獎勵",
- params: {
- bonus: 123
- }
- }
與業(yè)務(wù)接入方明確職責(zé)
為了讓活動SDK組件輕量，SDK內(nèi)使用的能力(比如：數(shù)據(jù)請求、登錄、錯誤監(jiān)控)通常由宿主環(huán)境(接入組件的業(yè)務(wù))提供。
這類能力分為兩類：
- 運行時業(yè)務(wù)方能提供的方法
- 業(yè)務(wù)方依賴的庫提供的能力
其中「運行時方法」可以作為props傳給SDK組件，比如登錄方法。
庫的能力，SDK需要將其定義為peerDependencies，比如React、ReactDOM。
- React技術(shù)棧需要確定SDK使用的React版本和業(yè)務(wù)使用的React版本需要同時在v16.14之前或之后，以防JSX被編譯為不同結(jié)果(_jsx.createElement與React.createElement)
與PM敲定活動流程
這一步和產(chǎn)品撕過的朋友都懂。
組件開發(fā)
完成了職責(zé)劃分，產(chǎn)出技術(shù)文檔，接下來就能開始「組件開發(fā)」了。
此時有兩點需要注意：
完善的類型提示
使用ts編寫組件，導(dǎo)出類型聲明文件，可以極大規(guī)范業(yè)務(wù)方接入，減少接入溝通成本。
錯誤邊界
如果SDK組件拋出錯誤，導(dǎo)致接入的頁面崩潰了，妥妥的p0級bug。
所以，一定要將SDK的錯誤catch在組件內(nèi)部。
對于React組件，用ErrorBoundary包裹是必不可少的。
業(yè)務(wù)接入
SDK組件終于開發(fā)完了，發(fā)布到公司內(nèi)部npm平臺。
業(yè)務(wù)方將SDK以npm包的形式引入。
此時需要考慮如下問題：
業(yè)務(wù)接入方以什么模塊規(guī)范導(dǎo)入(ESM還是CJS)?
如果接入方以SSR的形式在服務(wù)端接入組件，可能使用CJS規(guī)范。
CSR的情況通常使用ESM。
所以SDK組件在打包編譯時需要輸出ESM、CJS兩種規(guī)范的文件。
如果以ESM導(dǎo)出，需要考慮業(yè)務(wù)方treeShaking的需要
如果SDK會導(dǎo)出幾個組件(比如同一個活動組件對不同業(yè)務(wù)輸出不同版本)：
- // index.tsx
- export { default as Base } from './components/Base';
- export { default as SDKForA } from './components/SDKForA';
- export { default as SDKForB } from './components/SDKForB';
- export { default as SDKForC } from './components/SDKForC';
就需要考慮業(yè)務(wù)方的treeShaking需要。
當(dāng)前業(yè)界比較通用的方式是：將不同組件編譯到不同目錄，業(yè)務(wù)方通過組件目錄的形式引用，比如：
- // 業(yè)務(wù)方代碼
- import SDKForA from 'SDK/dist/modern/components/SDKForA';
其中SDK為活動組件導(dǎo)出的npm包。
dist為編譯后產(chǎn)物打包的目錄。
modern為ESM規(guī)范的打包路徑，如果要引入CJS的包，可以將modern改為node。
SDKForA為要引入的組件。
如果業(yè)務(wù)方使用了babel-plugin-import，以上寫法可以用如下寫法替代：
- // 業(yè)務(wù)方代碼
- import { SDKForA } from 'SDK';
除了js文件以外，還要考慮業(yè)務(wù)方對css文件的編譯需要。
所以組件樣式文件最好與組件分離，比如將如下路徑：
- - components
- - SDKForA
- - index.tsx
- - style.less
其中index.tsx內(nèi)引入了style.less
修改為：
- - components
- - SDKForA
- - index.tsx
- - styles
- - SDKForA
- - style.less
- - style.css
index.tsx不引入樣式文件，由業(yè)務(wù)方單獨引入。
樣式產(chǎn)出.css與.less兩種格式，當(dāng)業(yè)務(wù)方需要對樣式有進一步編譯需求，可以引入.less，否則直接引入.css。
業(yè)務(wù)方在接入時，可以這樣接入：
- // 業(yè)務(wù)方代碼
- import SDKForA from 'SDK/dist/modern/components/SDKForA';
- import 'SDK/dist/modern/styles/SDKForA/style.less';
上線
上線后前端就解放啦?NO!
刺激的事兒可都發(fā)生在線上～
隨著用戶量級提升，發(fā)生各種bug的概率也隨之提升，主要包括：
- 接口異常
- 靜態(tài)資源加載失敗
- 各種奇奇怪怪的宿主環(huán)境造成的報錯
- 關(guān)鍵活動進程的異常
這就需要做好線上監(jiān)控預(yù)警。
如果業(yè)務(wù)方引入了sentry，活動SDK可以為以上case埋點，并建立對應(yīng)監(jiān)控看板。
當(dāng)錯誤指標(biāo)超過閾值，可以隨時從被窩里爬起來排查問題。
除了代碼的埋點，業(yè)務(wù)埋點也很重要。某位不知名互聯(lián)網(wǎng)人說過：
我知道我做的活動會被薅羊毛，但我不知道究竟有多少羊毛被薅了
業(yè)務(wù)埋點能讓你知道。
總結(jié)
為了封裝一個不被吐槽的SDK組件，需要做到如下幾點：
明確組件職責(zé)，知道SDK能從宿主環(huán)境獲得什么能力
完善的ts聲明與錯誤邊界
靈活的導(dǎo)出產(chǎn)物，讓業(yè)務(wù)能舒服接入
上線后業(yè)務(wù)、代碼層面的監(jiān)控
說完這些，老卡又啄了一口保溫杯里的菊花枸杞茶，才發(fā)現(xiàn)：
茶，早已涼透。
