以登录模块为例，对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组件包裹，最终生成 <Tabs><TabPane/><TabPane/></Tabs>形式。非Tab组件，就按照原有模式渲染（<div>,<Submit>等）。
React.Children.forEach(children, item => {
if (!item) {
return;
}
if (item.type.__ANT_PRO_LOGIN_TAB) {
TabChildren.push(item);
} else {
otherChildren.push(item);
}
});
其中在Login组件中由如下代码，其目的是，将LoginItem中的表单元素集合统一配置在Login组件，便于组件间管理。其中LoginSubmit组件较为简单，就是对ant design中Button的封装，此处不再赘述。
Login.Tab = LoginTab;
Login.Submit = LoginSubmit;
Object.keys(LoginItem).forEach(item => {
Login[item] = LoginItem[item];
});
由以上分析可知，Login组件间的数据流如下图所示。
上一篇：ant design pro 代码学习(六) ----- 知识点总结2
开篇：ant design pro 代码学习(一) ----- 路由分析
