首先,我们以写代码这件事来举个例子.我们说好的代码里面,函数必须只满足一个功能.一旦,你的函数实现的效果太过于繁杂,那么,这就意味着其他地方需要修改这个函数的部分功能时,总会来这里做修改."牵一发而动全身",场景越来越复杂,总有改不动的一天.
通过上面的例子,我们回过头来聊组件,划分的原则:
一个组件只做一件事,基于功能做好职责划分.
我们需要在项目开发过程中,始终履行这个原则.在项目的初期,中期还是后期,往往会出问题的是初期.为啥?
因为开发初期,往往整体的系统功能单一,展现形式单一,这也误导我们做出错误的思考.
例如:开发一个信息查询系统,前期最多的就是输入框.可能一开始的输入框形式比较单一,校验形式单一,所以我们会将它统一封装成一个 text-input 组件.愚蠢的是,我们会将校验的逻辑写进组件里面,因为一开始的表单只有一种校验逻辑,写进组件中可以省下很多代码.
后来,突然增加了,一个验证码输入框,需要有部分内容去显示验证码.这时,我们会思考需不需要将之前的 text-input 进行拆解.但是,仅仅增加了一个验证码而已,我们完全可以使用 v-if 指令来控制这种情况.于是,草草了事,又在 text-input 上添了一个 props 去确认是否使用验证码组件.堂而皇之,之后的短信输入框来了,我们又可以在原先的验证码的基础上,增加短信按钮.而且由于整个信息查询系统,对于输入框的使用量剧增,开始出现不同的输入框校验方式.我们又得去输入框中,进行修改.总有我们不敢改的一天,因为不同业务线,使用的输入框组件,大多都是这个,不可能每次测试都会来测一下每条业务线的逻辑.
基于上诉情况,我们回过头来思考,我们为在前期做好一件事情--单一原则的划分.
撇开上述案例不谈,我们先来看看正常情况下,我们如何来划分组件的,如图:
这里依然扯到了无状态组件 (在 vue 中,我们可以考虑只使用 props 的组件).
理解一下 UI 组件:即 UI 单元,如输入框,tab 框,表格,下拉框.我们可以来看一下 2017 年 vue 的 UI 库发展情况:
可从图中看出,element 这个 vue 的 UI 库,增长的速度非常之快,或许是国内的教程大多数使用的 UI 库都是 element 的缘故吧,iView 同样在快速增长着.
移动端的 UI 库,同样也有 Mint UI 和 vux.
回到之前的话题,我们可以将组件分割成一个一个的业务组件,然后业务组件可以通过 UI 组件和无状态组件组成.这里的无状态组件可以给个定义:只接受 props,根据不同的 props 展现出不同的样式,并且会抛出事件来通知外部组件需要的更改.
回顾之前的案例,我们也可以进行如下的操作:
由于前期开发中对 text-input 这个组件塞入了太多不应该的东西.所以,我们需要一个将之前的短信,验证码,普通的输入框分成三个不同的业务组件.然后,可以使用既定的 UI 组件库来进行拼接.
还剩下一个容器组件:
它就相当于一个盒子,包含着各种业务组件,同时它也承接了各种数据,然后对这些数据进行分发.在组件的划分中容器组件扮演着至关重要的角色.
总结
我们将组件划分成三种组件:容器组件,无状态组件和 UI 组件.这样,我们就可以按照既定的原则去处理组件.同时,在拿到产品的原型稿时,我们也需要去认真地思考这个问题.我们可以将页面分成几个模块.
需要明白的是:
越小的单元,state 就越需要单一
不要在 UI 组件和无状态组件中进行数据的请求,应该将之放入容器组件中
单向原则,子组件不应该影响父组件
最后,希望你能够在实践中去进行运用.
来源: https://juejin.im/post/5a66fd9d6fb9a01c9332d337