如何封装不被讨厌的组件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)

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

（编辑：PHP编程网 - 黄冈站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!