机缘巧合之下,我在接到我司产品星级评价需求的前一天,看到了@蜗牛老湿★tiny-rate 东半球最小的评级组件☆,在大佬的启发下我就十分顺手的撸了一个移动端用的星级评价组件。

本篇会涉及的内容有:

  • 评价组件的实现
  • React组件开发浅谈
  • 小结&组件源码(不涉及业务)

星星评价组件的实现

组件的实现十分简单,基本都是参照tiny-rate的写法,就是在每颗星星的处理上有点区别:

星星填充的写法与tiny-rate类似,也是两层元素的叠加来模拟星星填充的效果,与之不同的是我给每颗星星(item)上都添加了点击事件,为了兼容我们在移动端的使用。点击每颗星星时,获取其序号,通过css3d的calc来计算出应该变化的宽度,从而达成星星填充的效果。

另外,由于☆与★在不同的手机上显示的效果可能不尽相同,但因为组件设计模式是叠加,所以我们可以将其替换成图片或是css画成的符号,以保证各端展示的统一。

最终的效果是这样滴–

React组件开发浅谈

其实本次主要想记录的内容是个人对React公用组件开发的一些看法–

明确组件功能

以这次的评价组件为例,在开发的是应该专注于评分的功能&显示,其他的需求(例如GIF中点击星级之后展示的文字说明)或附属功能都不应该写到组件内,造成组件与弱相关业务的耦合,这样才能为下次在其它情景中使用组件提供便利。

定义默认参数

作为一个公用的组件,对外暴露的Props是必不可少的,但是倘若我们在引用时,没有了解清楚必须的Props有哪些时,很容易会造成参数的缺失或错误。这种时候如果组件内没有定义相关的默认参数的话,会导致组件没法正常挂载或者是遍地红字。

以上述评级组件为例↓↓

1
2
3
4
5
6
7
// 在组件头部就应该定义支撑组件正常运行的Props参数
static defaultProps = {
canClick: true, // 可否点击
rateNum: 5, // 星星个数
handleSelectRate: null, // 选中星星后的回调
rateValue: 0 // 选中星星的个数
}

留意组件拓展

我们的项目肯定是不断在迭代的,所以我们在设计组件的时候也应该考虑到其灵活性,面对可能出现的需求迭代,应保留相应的配置空间。

如图中的width计算,在this.state.rateValue没有被赋值的情况下,我们会使用this.props.rateValue中的值来进行展示,这样就为我们的组件拓展出展示功能,不仅是在这个页面负责评分的选择,还可以在其他地方负责评分的显示。另外,组件的各种样式也应该是可拓展的方面之一。

需要暴露的API

作为一个非UI组件,自然是有其需要承担的功能性职责,这种时候就需要为其拟定相应的方法,有些方法是组件内部私有的,而有一些则应该暴露出来,让父级能够顺利调用。以评级组件为例,作为父组件,在使用该评级组件是最关心的是什么?没错,就是用户是否点击了你,并且用户点击了什么评级。这就很明了了,我们在编写组件时,应该在星星的点击事件上为父组件保留点击成功的响应。

1
2
3
4
5
6
7
8
9
10
handleSelectRate(value) {
if (!this.props.canClick) {
return
}
this.setState({
rateValue: value
})
// 点击成功后调用父组件传入的方法
this.props.handleSelectRate && this.props.handleSelectRate(value)
}

小结&组件源码(不涉及业务)

这些也不是啥干货,只是在平时工作开发中总结的一些东西,希望大大们轻拍。无论是用什么框架,组件应该都是绕不开的话题,如果能养成良好的组件开发思维,相信能让我们的开发效率得到提升,同时也能为其他同事提供便利。

源码环节–Github传送门

后话–为啥你敢把在用的组件源码直接丢出来??因为…它真的就只能用来点击评分…