以登录模块为例,对ant design pro的组件封装进行相关分析。登录模块包含基础组件的封装、组件按模块划分、同类组件通过配置文件生成、跨层级组件直接数据通信等,相对来说还是具有一定的代表性。
首先,全局了解一下登录模块的总体流程。如下图所示。该流程图主要分两部分:1、页面布局;2、组件封装。黄色实线表示页面中组件的引用。下边会对基础组件分析,以及多层级组件直接的数据处理。
由上图可知,所有的元素都是作为Login组件的children存在,依次包含Tab、UserName、Password、Mobile、Captcha、Submit。为了便于组件间关系更加明确,所有这些子组件都封装在Login组件中。
const {Tab, UserName, Password, Mobile, Captcha, Submit} = Login;
由以上介绍可知,Login作为其他组件的父组件。涉及到跨层数据通信,子组件可以通过context属性对Login的数据进行操作。
为便于对后续跨组件间数据通信有更好的了解,首先分析下跨层组件的数据模型。由React的API可知,如果需要用到context实现跨层级之间通信,首先需要在父组件中声明childContextTypes属性,并通过getChildContext返回对象,同时在使用context的子组件中通过contextTypes属性声明引用。
在父组件Login组件中,有如下context相关的代码:
......
static childContextTypes = {
tabUtil: PropTypes.object,
form: PropTypes.object,
updateActive: PropTypes.func,
};
......
getChildContext() {
return {
tabUtil: {
addTab: id => {
this.setState({
tabs: [...this.state.tabs, id],
});
},
removeTab: id => {
this.setState({
tabs: this.state.tabs.filter(currentId => currentId !== id),
});
},
},
form: this.props.form,
updateActive: activeItem => {
// type -- account、 mobile
//active 用来将account、mobile 的表单字段分类,便于提交校验。
const { type, active } = this.state;
if (active[type]) {
active[type].push(activeItem);
} else {
active[type] = [activeItem];
}
this.setState({
active,
});
},
};
}
childContextTypes对应的以上三个属性在组件中会被调用,子组件通过调用这些方法和属性,来改变父组件的状态。
LoginTab组件的处理比较简单,主要是以下三个部分:
LoginTab组件定义了两个静态属性:__ANT_PRO_LOGIN_TAB、contextTypes。
其中__ANT_PRO_LOGIN_TAB是为了给当前组件设置一个flag位。在Login组件中用于判断子组件是用LoginTab渲染还是其他处理方式;
contextTypes是配合context属性,跨层传递组件间的数据,声明引用父组件(声明childContextTypes的组件)中的tabUtil属性。
static __ANT_PRO_LOGIN_TAB = true;
static contextTypes = {
tabUtil: PropTypes.object,
};
LoginTab组件调用了生命周期函数componentWillMount,其目的是调用父组件中context返回的addTab方法。传递的参数,是生成的唯一字符串(generateId方法返回)。
componentWillMount() {
if (this.context.tabUtil) {
this.context.tabUtil.addTab(this.uniqueId);
}
}
render方法返回TabPane组件(引自 ant design Tab组件)。其中将父组件传递过来的prop全部继承,包含子组件。
render() {
return <TabPane {...this.props} />;
}
以下是generator部分代码。详细代码请参考原文件,此处只对关键代码进行分析。
function generator({ defaultProps, defaultRules, type }) {
return WrappedComponent => {
return class BasicComponent extends Component {
static contextTypes = {
form: PropTypes.object,
updateActive: PropTypes.func,
};
constructor(props) {
......
}
componentDidMount() {
if (this.context.updateActive) {
this.context.updateActive(this.props.name);
}
}
componentWillUnmount() {
clearInterval(this.interval);
}
onGetCaptcha = () => {
......
};
render() {
......
const { getFieldDecorator } = this.context.form;
......
//组件参数
const { onChange, defaultValue, rules, name, ...restProps } = this.props;
......
return (
<FormItem>
{getFieldDecorator(name, options)(
<WrappedComponent {...defaultProps} {...otherProps} />
)}
</FormItem>
);
}
};
};
}
由上述代码可知,generator 是一个高阶函数,返回的是BasicComponent类,BasicComponent本质上一个组件:组件类型取决于参数WrappedComponent,组件属性取决于参数defaultProps、defaultRules(默认参数),以及组件引用时传递的props参数(this.props)(动态参数)。
其中,contextTypes中申明的form属性,来自于父组件Login中的【Form.create()(Login)】form属性,因此可以使用getFieldDecorator对表单元素绑定。(这也说明,generator是表单元素生成器)。
render方法中,当type==='Captcha’时,有做特殊处理。该部分逻辑对应的业务是通过手机号获取验证码。对应的
onGetCaptcha方法设定了获取验证码的倒计时逻辑。componentWillUnmount中对定时器清楚。
componentDidMount方法,将props属性中的name属性传递给context中的updateActive方法。在第2部分已经阐述过,updateActive方法根据type(accout,mobile)来区分各自的表单字段,便于数据校验和数据提交。
map.js 本质上是一个配置文件,其内容为登录模块中表单元素的配置,通过对配置文件数据的处理,得到对应的表单元素组件(详见4.3)。以下边代码为例,该配置文件的key(UserName)即为组件名称,即生成UserName组件,component表示UserName组件最终返回的组件,即UserName组件本质上是Input组件,其中props中的参数与ant design 组件Input的属性保持一致。rules属性,包含当前组件需要满足的约束、规则,该表单元素最终会通过form属性中提供的方法进行数据绑定,因此rules属性与ant design 组件Form表单的属性保持一致。
const map = {
UserName: {
component: Input,
props: {
size: 'large',
prefix: <Icon type="user" className={styles.prefixIcon} />,
placeholder: 'admin',
},
rules: [
{
required: true,
message: 'Please enter username!',
},
],
}
}
通过循环遍历配置文件map中的key,通过4.1 generator生成器分析可知,调用generator方法后,生成的LoginItem[item] 组件,实际上是map[item].component元素(配置文件中component属性),同时传入的默认参数、默认校验分别为map[item].props、map[item].rules(配置文件中props,rules属性),其中type是为了对特殊元素进行处理。
const LoginItem = {};
Object.keys(map).forEach(item => {
LoginItem[item] = generator({
defaultProps: map[item].props,
defaultRules: map[item].rules,
type: item,
})(map[item].component);
});
表单元素通过统一的配置文件map.js形成集合,循环遍历配置文件map.js,生成对应的表单元素组件。其中表单元素组件的最终的展现形式取决于配置文件中的component属性;结合表单元素引用时的动态属性(onChange、defaultValue、name等)和配置文件中的静态属性(props),确定该组件最终的属性;结合表单元素引用时的rules属性和配置文件的rules属性,确定最终的校验规则。其中props、rules都符合ant design组件库中相关组件的配置属性。(文档流)
所有的表单组件作为Login的子组件,通过调用context属性对数据进行关联。调用form属性中的getFieldDecorator对表单元素进行数据绑定。调用updateActive对表单元素根据tab类型进行分类。(数据流)
Login组件作为其他子组件的父组件,通过childContextTypes、getChildContext完成与子组件的数据交互(当然子组件中需要声明),关于数据流部分,已在上文中各个模块处都有详解,此处不再赘述。
处理Tab切换,以及表单提交等事件。其中子组件生成时已经根据tab组件的类型(accout、mobile)对表单元素进行划分,因此在校验时,只需要对当前tab组件下的表单进行校验和提交。因此有如下代码:
handleSubmit = e => {
e.preventDefault();
const { active, type } = this.state;
const activeFileds = active[type];
this.props.form.validateFields(activeFileds, { force: true }, (err, values) => {
this.props.onSubmit(err, values);
});
};
其中type为当前tab组件的类型。则activeFileds为当前tab组件下的表单元素,因此校验时,只需要调用this.props.form.validateFields方法对activeFileds校验(https://ant.design/components/form-cn/) ,校验通过则调用接口向后台业务传递数据(routes/User/Login中定义)。
其中,render方法中,下边这段代码的主要作用是为了判断Login组件的子元素是否是Tab组件。其中Tab组件引用来自LoginTab。LoginTab组件中定义了静态属性__ANT_PRO_LOGIN_TAB,该字段目的就是为了区分是否是Tab组件(最终形式为TabPane)。其中Tab组件最终被ant desgin的Tabs组件包裹,最终生成 其中在Login组件中由如下代码,其目的是,将LoginItem中的表单元素集合统一配置在Login组件,便于组件间管理。其中LoginSubmit组件较为简单,就是对ant design中Button的封装,此处不再赘述。 由以上分析可知,Login组件间的数据流如下图所示。 上一篇:ant design pro 代码学习(六) ----- 知识点总结2
形式。非Tab组件,就按照原有模式渲染( React.Children.forEach(children, item => {
if (!item) {
return;
}
if (item.type.__ANT_PRO_LOGIN_TAB) {
TabChildren.push(item);
} else {
otherChildren.push(item);
}
});
5.4 组件统一管理
Login.Tab = LoginTab;
Login.Submit = LoginSubmit;
Object.keys(LoginItem).forEach(item => {
Login[item] = LoginItem[item];
});
6、 Login组件间的数据流
开篇:ant design pro 代码学习(一) ----- 路由分析