业务组件和逻辑复用的方向

[aermin]

起因

最近用团队里面共用组件库，发现一个现象，就是经常有一个组的开发去写了一个页面(panel)，放在组件库里面，然后其他产品组的同学看到页面可能有一定的相似度，就去拿这个panel来用，因为还是和自己产品有一定的出入，就直接传了很多props做为判断条件去显示/隐藏 各种定制化的renderprops塞进这个panel中，到后面这个panel被塞进了各种不通用的props，logic和element，代码量越堆越大，阅读性不佳，不利于维护，还会让其他产品组引用这个panel的时候引入了很多本不需要的冗余代码，文件越大影响页面加载速度。

我是“可复用”的部分     产品A的开发：我们需要在里面显示不同的东西，所以我塞进来好了，简单粗暴        产品B的开发：俺也一样
################     
##############
                 <===塞进去==   const logicA = …...
                 <===塞进去==   {props.showA && AAAAAAAAAAAAAAAA}                                                                           
                                                                              <===塞进去==   const logicB = …...
                                                                              <===塞进去==   {props.showB &&BBBBBBBBBBBBB}           
##############
################

方案

思来想去，我拿了一个相对复杂而且被乱塞的panel来重构，重构的思路是把panel，根据不同通用化的需求，拆分成不同粒度的通用化组件，和可复用的逻辑，然后大家使用的时候，就像搭积木一样去搭建自己的panel，当然还是可以提供(搭)一个可能多产品可以直接拿来用的panel当做默认模板，但是只要有部分不同的需求，请拿给你封装好的细粒度的组件去搭，而不是在默认panel堆代码。

我们需要复用的是通用的业务逻辑和细粒度的组件，所以把这些抽出来复用，而不是去写一个wrapper panel然后里面塞各种不通用的东西。

我是可复用的小组件
XXXXXXXXXXXXXXXX

我是可复用的小组件
YYYYYYYYYYYYYYY

我是可复用的小组件
ZZZZZZZZZZZZZZZ

说到业务逻辑的复用，可以搬出React现有的三种方式： Hook，Renderprops，HOC

我是可复用的业务逻辑
I-AM-A-HOOK

我是可复用的业务逻辑
I-AM-A-RENDER-PROPS

我是可复用的小组件
I-AM-A-HOC

然后跟团队里的开发们一起谈论此方案并形成共识，以后：

产品A的开发：我们有特有的逻辑和UI部分，所以不去拿默认panel来用，而是拿需要的通用的组件和hook业务逻辑来搭建属于自己的panel

const logicA = …...
I-AM-A-HOOK

XXXXXXXXXXXXXXXX

AAAAAAAAAAAAAAA

ZZZZZZZZZZZZZZZ