摘要：一前言在導(dǎo)讀三中介紹了項(xiàng)目的背景功能需求項(xiàng)目結(jié)構(gòu)以及組件的劃分層次，接下來我們就來看下實(shí)際的代碼，這一篇文章會(huì)主要分享用到的基礎(chǔ)組件的封裝。

在 React 導(dǎo)讀（三） 中介紹了項(xiàng)目的背景、功能需求、項(xiàng)目結(jié)構(gòu)以及組件的劃分層次，接下來我們就來看下實(shí)際的代碼，這一篇文章會(huì)主要分享用到的基礎(chǔ)組件的封裝。

我們?cè)谠O(shè)計(jì)組件之前本來是有一個(gè)流程和過程的，這里我寫的組件并不會(huì)像社區(qū)內(nèi)的組件庫一樣完善或者說一定考慮很完整，但是這樣也會(huì)有一個(gè)好處，可以按照自己項(xiàng)目的需求進(jìn)行定制、擴(kuò)展以及冗余的代碼會(huì)更少，當(dāng)然很多時(shí)候節(jié)約的這點(diǎn)代碼可以忽略不計(jì)(特別是項(xiàng)目業(yè)務(wù)代碼和庫的代碼比例上升到一定比例過后，所以一切不說場(chǎng)景就說某某庫太大的觀點(diǎn)都是不正確的)，因?yàn)榇蠹叶加邪葱杓虞d的配置可選。這不是絕對(duì)的，不一定說你自己花時(shí)間和精力去開發(fā)一個(gè)這樣的庫就更好，因?yàn)?strong>隨著項(xiàng)目規(guī)模的擴(kuò)大，組件的種類和需求會(huì)越來越多，即使是一個(gè)不錯(cuò)的工程師利用技巧保障項(xiàng)目持續(xù)迭代，但是人的時(shí)間和精力是有限的，更合理的利用現(xiàn)有資源去提高效率才是最優(yōu)先考慮的事情。

我這里的基礎(chǔ)組件實(shí)現(xiàn)了這么幾個(gè)：
Button, Dialog, Input, Loading, Table

然后分別來介紹一下如何基礎(chǔ)開始封裝和拆合組件。其實(shí)基礎(chǔ)組件的設(shè)計(jì)是很殺腦細(xì)胞的，如果要考慮很周全的話，因?yàn)橐骖檮e人用的爽，也盡可能要保留可擴(kuò)展性，基礎(chǔ)組件如果擴(kuò)展性太弱，基本等于廢了。其實(shí)如果有學(xué)習(xí)設(shè)計(jì)模式是可以相互連接的，因?yàn)樵O(shè)計(jì)模式是成熟的經(jīng)驗(yàn)，不是說非要在寫某種邏輯代碼或者做架構(gòu)設(shè)計(jì)的時(shí)候才能使用，它是能夠貫穿在整個(gè)軟件周期內(nèi)的。

(1) 思考想要如何去組織組件樣式

首先這里的組件是 css 和 js 最好能夠分開使用的(這里的分開使用不是指?jìng)鹘y(tǒng)意義的分離，而是保持獨(dú)立，可進(jìn)可退)，拿以前 UI 需求來看，就是在同一個(gè)結(jié)構(gòu)的 HTML，加上 class 都是能夠正常展現(xiàn)的，我這里的 css 結(jié)構(gòu)是以前用過的，也沒做什么改動(dòng)直接拿過來使用的。這種設(shè)計(jì)思路其實(shí)和現(xiàn)在的組件化開發(fā)是不沖突的，組件化后還能夠使得這種模式更簡(jiǎn)單的被實(shí)現(xiàn)，因?yàn)槟阒恍枰紤]組件這個(gè)作用域內(nèi)的樣式。

(2) Dialog 組件
這里先拿 Dialog 組件先舉例，這里我將彈框組件分成了三部分：DialogHeader, DialogFooter, Dialog 拆分上也沒什么理由，這是一種簡(jiǎn)單直接的拆分，因?yàn)楹芏鄰椏蚨季哂羞@么幾部分：標(biāo)題、內(nèi)容、按鈕區(qū)域。

而且不只是這樣的才叫彈框，彈框如其名：彈出的框，所以都是可以的，比如下面這種像個(gè) Alert 一樣的彈框：

我理解的好擴(kuò)展的組件就像小時(shí)候玩的玩具一樣，各部分都是可拆解可組合的，所以彈框的這三部分都需要有一定靈活的地方。來看看代碼，其實(shí)蠻簡(jiǎn)單的。

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 (
            

                

                    {header}
                    {this.props.children}
                    {footer}
                
                

            
        );
    }
}

上面就是一個(gè)我這里 Dialog 的結(jié)構(gòu)，header和footer采用的是render-props的方式來實(shí)現(xiàn)具體的插入，為什么能夠采用這種方式其實(shí)不難理解，因?yàn)樵?React 中，一個(gè)函數(shù)就自然就是一個(gè)組件聲明，返回值就能是一個(gè)組件實(shí)例。我這里更直接，你要組件返回值，我就給你一個(gè)組件...使用上就是這樣：

// 這里結(jié)構(gòu)稍微代碼有點(diǎn)多，就不要揉在一起了，給一個(gè)變量存一下更清晰，在 React 中組件的使用是自由的。
const footer = (
    
);

 }
    renderFooter={() => footer}>
    
...

為什么要這樣設(shè)計(jì)呢？主要還是因?yàn)橛袝r(shí)候需求不定，萬一哪天 DialogFooter 組件不是這樣子，我就在外面實(shí)現(xiàn)好組件給這個(gè)renderFooter就行了，其他部分就不需要改動(dòng)，還有就是實(shí)現(xiàn)的時(shí)候不要吝嗇div這種容器標(biāo)簽的使用，多一層就多一個(gè)權(quán)重，少一層就多了一份自由。

現(xiàn)在還有一個(gè)問題，就是我的基礎(chǔ)彈框有了，業(yè)務(wù)彈框各種各樣，這么簡(jiǎn)單的一個(gè)封裝根本不靠譜啊...那么這里你就將彈框作為一個(gè)流行的渲染組件來使用，但是是否掛載到業(yè)務(wù)模塊中就使用封裝的一層業(yè)務(wù)彈框來控制，比如我的業(yè)務(wù)彈框叫 EmployeeAddDialog，在 render 方法中：

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

return (
);

通過一個(gè) visible 的 props 值來控制是否掛載 Dialog，那么這樣做就有一個(gè)好處，在處理異步彈框的時(shí)候，想什么時(shí)候關(guān)閉彈框可以由業(yè)務(wù)的流程來控制。在業(yè)務(wù)組件聲明業(yè)務(wù)彈框的地方就這樣：

然后這樣就實(shí)現(xiàn)了一個(gè)彈框了，靈活性和擴(kuò)展性都還好，最后還有一個(gè)細(xì)節(jié)就是這個(gè)EmployeeAddDialog始終都掛載在業(yè)務(wù)組件中，業(yè)務(wù)組件渲染一次這個(gè)彈框更新周期也會(huì)走一次，所以能夠繼承一下PureComponent來簡(jiǎn)單避免多次執(zhí)行不必要代碼：

class EmployeeAddDialog extends React.PureComponent { }

看上去這個(gè)彈框組件還算干凈，不可能啊，業(yè)務(wù)太復(fù)雜也不會(huì)太干凈，那么臟的東西去哪兒了呢？我這里有 2 個(gè)比較臟的地方：

(1) Footer，因?yàn)橛邪粹o，每個(gè)需求的按鈕是不一樣的；
(2) 彈框的內(nèi)容，這里就更是千奇百怪，每個(gè)產(chǎn)品經(jīng)理的腦洞都不一樣。

我這里應(yīng)對(duì)上 Footer 有一定的定制又有簡(jiǎn)單的開關(guān)，比如我就支持2個(gè)按鈕：提交類、關(guān)閉類。

彈框內(nèi)容我控制不了，那么我就把代碼是否更臟的職責(zé)交出去，使用了 this.props.children來做這個(gè)事情，使用者的代碼干凈度來決定最后的業(yè)務(wù)彈框干凈度。

具體的全部代碼能夠在這里看到：

基礎(chǔ) Dialog

業(yè)務(wù) Dialog

今天先到這里吧，睡覺了?