一、媒介

在 React 导读（三） 中引见了项目的背景、功用需求、项目构造以及组件的分别条理，接下来我们就来看下现实的代码，这一篇文章会重要分享用到的基础组件的封装。

二、基础组件设想

我们在设想组件之前本来是有一个流程和历程的，这里我写的组件并不会像社区内的组件库一样完美或许说肯定斟酌很完全，然则如许也会有一个优点，可以根据本身项目的需求举行定制、扩展以及冗余的代码会更少，固然许多时刻勤俭的这点代码可以忽略不计(特别是项目营业代码和库的代码比例上升到肯定比例事后，所以统统不说场景就说某某库太大的看法都是不正确的)，由于人人都有按需加载的设置可选。这不是相对的，不肯定说你本身花时候和精神去开辟一个如许的库就更好，由于跟着项目范围的扩展，组件的品种和需求会越来越多，即使是一个不错的工程师应用技能保证项目延续迭代，然则人的时候和精神是有限的，更合理的应用现有资本去进步效力才是最优先斟酌的事变。

我这里的基础组件完成了这么几个：
Button, Dialog, Input, Loading, Table

然后分别来引见一下怎样基础最先封装和拆合组件。实在基础组件的设想是很杀脑细胞的，假如要斟酌很全面的话，由于要统筹他人用的爽，也尽可能要保存可扩展性，基础组件假如扩展性太弱，基础即是废了。实在假如有进修设想形式是可以相互连接的，由于设想形式是成熟的履历，不是说非要在写某种逻辑代码或许做架构设想的时刻才运用，它是可以贯穿在悉数软件周期内的。

(1) 思索想要怎样去构造组件款式

起首这里的组件是 css 和 js 最好可以离开运用的(这里的离开运用不是指传统意义的星散，而是坚持自力，可进可退)，拿之前 UI 需求来看，就是在同一个构造的 HTML，加上 class 都是可以一般展示的，我这里的 css 构造是之前用过的，也没做什么修改直接拿过来运用的。这类设想思绪实在和如今的组件化开辟是不争执的，组件化后还可以使得这类形式更简朴的被完成，由于你只须要斟酌组件这个作用域内的款式。

(2) Dialog 组件
这里先拿 Dialog 组件先举例，这里我将弹框组件分成了三部份：DialogHeader, DialogFooter, Dialog 拆分上也没什么来由，这是一种简朴直接的拆分，由于许多弹框都具有这么几部份：题目、内容、按钮地区。

而且不只是如许的才叫弹框，弹框如其名：弹出的框，所以都是可以的，比方下面这类像个 Alert 一样的弹框：

我明白的好扩展的组件就像小时刻玩的玩具一样，各部份都是可拆解可组合的，所以弹框的这三部份都须要有肯定天真的处所。来看看代码，实在蛮简朴的。

class Dialog extends React.Component {
    render() {
        const {
            renderHeader,
            renderFooter,
            className,
        } = this.props;

        const header = renderHeader ? renderHeader() : null;
        const footer = renderFooter ? renderFooter() : null;

        const wrapClassName = cx('st-dialog', className);

        return (
            <div className={wrapClassName}>
                <div className="st-dialogContent">
                    {header}
                    {this.props.children}
                    {footer}
                </div>
                <div className="st-dialogMask"></div>
            </div>
        );
    }
}

上面就是一个我这里 Dialog 的构造，header和footer采纳的是render-props的体式格局来完成详细的插进去，为何可以采纳这类体式格局实在不难明白，由于在 React 中，一个函数就天然就是一个组件声明，返回值就可以是一个组件实例。我这里更直接，你要组件返回值，我就给你一个组件…运用上就是如许：

// 这里构造轻微代码有点多，就不要揉在一起了，给一个变量存一下更清楚，在 React 中组件的运用是自在的。
const footer = (
    <DialogFooter
        onSubmit={this.handleSubmit}
        onClose={this.handleClose}
        submitText="增加"
        closeText="封闭" />
);

<Dialog className="employeeAddDialog"
    renderHeader={() => <DialogHeader title="增加成员" />}
    renderFooter={() => footer}>
    <div className="addDialog">...</div>
</Dialog>

为何要如许设想呢？重要照样由于有时刻需求不定，万一哪天 DialogFooter 组件不是如许子，我就在表面完成好组件给这个renderFooter就好了，其他部份就不须要修改，另有就是完成的时刻不要悭吝div这类容器标签的运用，多一层就多一个权重，少一层就多了一份自在。

如今另有一个题目，就是我的基础弹框有了，营业弹框林林总总，这么简朴的一个封装基础不靠谱啊…那末这里你就将弹框作为一个盛行的衬着组件来运用，然则是不是挂载到营业模块中就运用封装的一层营业弹框来掌握，比方我的营业弹框叫 EmployeeAddDialog，在 render 要领中：

if(!this.props.visible) {
    return null;
}

return (<Dialog />);

经由过程一个 visible 的 props 值来掌握是不是挂载 Dialog，那末如许做就有一个优点，在处置惩罚异步弹框的时刻，想什么时刻封闭弹框可以由营业的流程来掌握。在营业组件声明营业弹框的处所就如许：

<EmployeeAddDialog visible={this.state.visibleAddDialog}
onClose={this.handleCloseAddDialog} />

然后如许就完成了一个弹框了，天真性和扩展性都还好，末了另有一个细节就是这个EmployeeAddDialog一直都挂载在营业组件中，营业组件衬着一次这个弹框更新周期也会走一次，所以可以继续一下PureComponent来简朴防止屡次实行不必要代码：

class EmployeeAddDialog extends React.PureComponent { }

看上去这个弹框组件还算清洁，不可能啊，营业太庞杂也不会太清洁，那末脏的东西去哪儿了呢？我这里有 2 个比较脏的处所：

(1) Footer，由于有按钮，每一个需求的按钮是不一样的；
(2) 弹框的内容，这里就更是光怪陆离，每一个产物司理的脑洞都不一样。

我这里应对上 Footer 有肯定的定制又有简朴的开关，比方我就支撑2个按钮：提交类、封闭类。

弹框内容我掌握不了，那末我就把代码是不是更脏的职责交出去，运用了 this.props.children来做这个事变，运用者的代码清洁度来决议末了的营业弹框清洁度。

详细的悉数代码可以在这里看到：

基础 Dialog

营业 Dialog

本日先到这里吧，睡觉了?