gpt4 book ai didi

如何封装不被嫌弃的组件SDK

转载 作者:qq735679552 更新时间:2022-09-28 22:32:09 26 4
gpt4 key购买 nike

CFSDN坚持开源创造价值,我们致力于搭建一个资源共享平台,让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章如何封装不被嫌弃的组件SDK由作者收集整理,如果你对这篇文章有兴趣,记得点赞哟.

如何封装不被嫌弃的组件SDK

你在一家小互联网公司做前端。最近公司发展势头不错,已经有了稳定的商业模式。老板决定尝试付费推广.

马上五一了,老板想策划一个活动玩法。可是公司前端人力有限,不能每个业务都单独开发活动.

于是老板找到了你,希望你封装一个活动SDK组件供公司几个业务接入.

你心里嘀咕:平时组件写的倒是很多,也写过公共组件,活动组件感觉就是带业务逻辑的公共组件,应该没啥难度吧?

但是你心里没底,怕自己封装的组件SDK被接入的业务方嫌弃,就去请教公司最资深(发量最少)的前端老卡.

待说明来意,老卡深深啄了一口保温杯里的菊花枸杞茶.

如何封装不被嫌弃的组件SDK

“这封装组件SDK的门道啊,分为组件设计、开发、接入、上线,待我一一道来”.

组件设计好的组件设计需要做到「职责明确」。在设计阶段需要与3个角色明确职责:

与提供数据的服务端明确职责

  。

活动内部需要的数据通常由服务端提供,此时需要明确字段的粒度.

比如:邀请新用户得xxx元奖励 。

xxx是变量,通常会作为一个字段.

那么「邀请新用户得 元奖励」这段文案呢?活动进程中,有没有可能PM发现这段文案效果不好想修改.

如果前端写死了文案,要修改意味着组件提供方(你)与业务接入方都有重新上线的成本.

所以,如果评估有修改的可能,更好的方式可能是将这段文案下发为类似结构:

  1. data: { 
  2.   title: "邀请新用户得{{bonus}}元奖励"
  3.   params: { 
  4.     bonus: 123 
  5.   } 

与业务接入方明确职责

  。

为了让活动SDK组件轻量,SDK内使用的能力(比如:数据请求、登录、错误监控)通常由宿主环境(接入组件的业务)提供.

这类能力分为两类:

  • 运行时业务方能提供的方法
  • 业务方依赖的库提供的能力

其中「运行时方法」可以作为props传给SDK组件,比如登录方法.

库的能力,SDK需要将其定义为peerDependencies,比如React、ReactDOM.

  • React技术栈需要确定SDK使用的React版本和业务使用的React版本需要同时在v16.14之前或之后,以防JSX被编译为不同结果(_jsx.createElement与React.createElement)

与PM敲定活动流程

  。

这一步和产品撕过的朋友都懂.

如何封装不被嫌弃的组件SDK

组件开发

  。

完成了职责划分,产出技术文档,接下来就能开始「组件开发」了.

此时有两点需要注意:

完善的类型提示

  。

使用ts编写组件,导出类型声明文件,可以极大规范业务方接入,减少接入沟通成本.

错误边界

  。

如果SDK组件抛出错误,导致接入的页面崩溃了,妥妥的p0级bug.

所以,一定要将SDK的错误catch在组件内部.

对于React组件,用ErrorBoundary包裹是必不可少的.

如何封装不被嫌弃的组件SDK

业务接入

  。

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.

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

如何封装不被嫌弃的组件SDK

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

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

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

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

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

如何封装不被嫌弃的组件SDK

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

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

业务埋点能让你知道.

总结

  。

为了封装一个不被吐槽的SDK组件,需要做到如下几点:

明确组件职责,知道SDK能从宿主环境获得什么能力 。

完善的ts声明与错误边界 。

灵活的导出产物,让业务能舒服接入 。

上线后业务、代码层面的监控 。

说完这些,老卡又啄了一口保温杯里的菊花枸杞茶,才发现:

茶,早已凉透.

原文地址:https://mp.weixin.qq.com/s/vbRkCgncWZswqnrz30LiLQ 。

最后此篇关于如何封装不被嫌弃的组件SDK的文章就讲到这里了,如果你想了解更多关于如何封装不被嫌弃的组件SDK的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com