业务接入

SDK组件终于开发完了，发布到公司内部npm平台。

业务方将SDK以npm包的形式引入。

此时需要考虑如下问题：

业务接入方以什么模块规范导入(ESM还是CJS)?

如果接入方以SSR的形式在服务端接入组件，可能使用CJS规范。

CSR的情况通常使用ESM。

所以SDK组件在打包编译时需要输出ESM、CJS两种规范的文件。

如果以ESM导出，需要考虑业务方treeShaking的需要

如果SDK会导出几个组件(比如同一个活动组件对不同业务输出不同版本)：

1. // index.tsx 
2. export { default as Base } from './components/Base'; 
3. export { default as SDKForA } from './components/SDKForA'; 
4. export { default as SDKForB } from './components/SDKForB'; 
5. export { default as SDKForC } from './components/SDKForC'; 

就需要考虑业务方的treeShaking需要。

当前业界比较通用的方式是：将不同组件编译到不同目录，业务方通过组件目录的形式引用，比如：

1. // 业务方代码 
2. import SDKForA from 'SDK/dist/modern/components/SDKForA'; 

其中SDK为活动组件导出的npm包。

dist为编译后产物打包的目录。

modern为ESM规范的打包路径，如果要引入CJS的包，可以将modern改为node。

SDKForA为要引入的组件。

如果业务方使用了babel-plugin-import，以上写法可以用如下写法替代：

1. // 业务方代码 
2. import { SDKForA } from 'SDK'; 

除了js文件以外，还要考虑业务方对css文件的编译需要。

所以组件样式文件最好与组件分离，比如将如下路径：

1. – components 
2.   – SDKForA 
3.     – index.tsx 
4.     – style.less 

其中index.tsx内引入了style.less

修改为：

1. – components 
2.   – SDKForA 
3.     – index.tsx 
4. – styles 
5.   – SDKForA 
6.     – style.less 
7.     – style.css 

index.tsx不引入样式文件，由业务方单独引入。

样式产出.css与.less两种格式，当业务方需要对样式有进一步编译需求，可以引入.less，否则直接引入.css。

业务方在接入时，可以这样接入：

1. // 业务方代码 
2. import SDKForA from 'SDK/dist/modern/components/SDKForA'; 
3. import 'SDK/dist/modern/styles/SDKForA/style.less'; 

上线

上线后前端就解放啦?NO!

刺激的事儿可都发生在线上～

随着用户量级提升，发生各种bug的概率也随之提升，主要包括：

• 接口异常
• 静态资源加载失败
• 各种奇奇怪怪的宿主环境造成的报错
• 关键活动进程的异常

这就需要做好线上监控预警。

如果业务方引入了sentry，活动SDK可以为以上case埋点，并建立对应监控看板。

当错误指标超过阈值，可以随时从被窝里爬起来排查问题。

除了代码的埋点，业务埋点也很重要。某位不知名互联网人说过：

我知道我做的活动会被薅羊毛，但我不知道究竟有多少羊毛被薅了