组件的一些思考

如今数据驱动视图的框架已经成为前端开发的主流,如react、vue、angular等,当然还包括我们用的regular。这些框架大大提高了我们的开发效率,但同时现在的页面结构越来越复杂,虽然有这些mv*的框架,但如果我们使用不当,也会造成状态数据管理混乱,代码难以维护的困扰。

因此组件化的思想就是为了提高开发效率和后期维护的效率。

什么是组件化

一个组件只做一件事,基于功能做好职责划分。

对组件的封装都是为了对数据逻辑业务的梳理,使得不同组件各司其职,即把大块的业务界面,拆分成若干小块,然后进行组装。当然这里不局限与js,其实css同样适用(如nec规范)。

组件的划分

module-and-components

无状态组件

数据驱动视图,顾名思义视图的状态肯定是根据数据进行变化的,因此数据的状态管理就变得尤为重要。

无状态组件为只接受props,根据props的不同展示出不同的样式,并且会抛出事件来通知外部组件需要的更改(ps. 按照react以及vue的单向绑定原则,props传入是不能被更改的,这和regular的双向绑定不同)

单向绑定能更好的帮助我们控制住数据的状态,特别对于越来越复杂的前端

UI组件

这部分就是我们视图上看到的各个UI单元,如输入框、tab框、表格、下拉框等等,其中有一些其实可以是我们上述所说的无状态组件,我们常见的UI库如ant-design(react)、eleme-element(vue)以及nek、kmui等。

特点:复用性强,根据接受参数显示不同的视图,以及开放一些接口与外部通信。就如同一个对html标签的扩展

业务组件

就是按照一个页面的业务逻辑进行划分的单元,如优惠券、商品1x2、商品1x3、倒计时等等,它们中有一些有一定的复用性,但大部分可能只会在特定的业务中使用。它们里面是由一个个UI组件组成。

容器组件

一个包裹业务模块的盒子,一般来说一个业务模块的入口。它接收着业务组件所需要的所有数据,然后根据每个业务组件的需要来进行分发数据,使对应的数据进入到对应的业务组件中。如下是一个使用了redux和react的container组件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import {connect} from 'react-redux';
import Topic from '../components/topic';
const mapStateToProps = (state) => {
return {
info: state.topicInfo
}
}
const mapDispatchToProps = (dispatch) => {
}
export default connect(mapStateToProps, mapDispatchToProps)(Topic)

上面的container就是将topic的业务组件进行了一个包裹并将数据通过props传入给了topic。

组件的原则

  1. state状态应尽量简单
  2. 单向原则,子组件不应该影响父组件,当某个子组件删除后,只会影响此子组件的UI展示,其他组件都不应该产生影响
  3. 参数的扁平化,接收的props应该尽量做到是基本数据类型。