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