[[356515]]

 一、寫在前面

現(xiàn)今的web開發(fā)通過前后端分離的技術(shù)拆分為了web后端開發(fā)與web前端開發(fā)，值得指出的是，web前端開發(fā)早已不是傳統(tǒng)意義上的開發(fā)模式了，轉(zhuǎn)而變成了web客戶端開發(fā)，有過客戶端開發(fā)經(jīng)驗(yàn)的同學(xué)應(yīng)該知道這兩者間的差別，客戶端開發(fā)關(guān)注的是：

1. 應(yīng)用的生命周期
2. 組件化
3. 開發(fā)模式與打包方法

組件化是客戶端開發(fā)最重要的內(nèi)容，設(shè)計(jì)一套復(fù)用度高、擴(kuò)展性好的組件系統(tǒng)，可以顯著提高開發(fā)效率，并且可以減少后期的維護(hù)成本。

二、一個(gè)筆記組件的設(shè)計(jì)案例

就以我正在使用的筆記app為例，上圖展示的筆記的閱讀與書寫區(qū)域，如何將這個(gè)區(qū)域抽象為一個(gè)組件呢?讓我們一步一步來分析。

1. 最簡(jiǎn)api

我們?yōu)樵摻M件取個(gè)名字(取名很重要)，就叫Note吧。不管是在閱讀狀態(tài)還是在編輯狀態(tài)，該組件都要展示筆記的內(nèi)容，因?yàn)楣P記對(duì)象應(yīng)該通過組件的接口傳入進(jìn)來，因?yàn)槲覀優(yōu)樵摻M件設(shè)計(jì)第一個(gè)api：

屬性說明類型是否必填data筆記對(duì)象數(shù)據(jù)object是

接下來，我們簡(jiǎn)單使用一下這個(gè)組件：

為了兼容vue與react的讀者，本頁(yè)面均使用JSX語(yǔ)法

const note = { 
    title:  如何制作一個(gè)組件？.md , 
    content:    
} 

 這樣，一個(gè)最簡(jiǎn)api的筆記組件就搞定了，它的接口非常簡(jiǎn)單，只需要提供一個(gè)data屬性，就可以展示出筆記內(nèi)容，并且可以點(diǎn)擊編輯進(jìn)入書寫狀態(tài)。

一般而言，如果沒有更多的需求的話，我們的筆記組件設(shè)計(jì)到這里也就可以了。**在設(shè)計(jì)組件時(shí)，務(wù)必遵循最小化原則，即盡可能少地拋出接口。**因?yàn)槭褂媒M件的用戶可能有很多，一旦組件作者不小心拋出了一個(gè)不合理的接口，以后想要修改就幾乎不可能了(只能通過標(biāo)記過時(shí)的方法提醒用戶，但這種做法往往是無奈之舉)。

2. 滿足數(shù)據(jù)獲取的多種情況

現(xiàn)在，組件的使用者已經(jīng)可以通過很簡(jiǎn)潔的api使用這個(gè)筆記組件了，但是現(xiàn)在問題來了：有的組件使用者只拿到了筆記的id，想要通過直接傳入id的方式使用組件。

此時(shí)，作為組件作者，我們?cè)u(píng)估了這個(gè)需求是合理的，于是，我們擴(kuò)展了筆記組件的api：

屬性說明類型是否必填默認(rèn)值data筆記對(duì)象object否nulldataId筆記對(duì)象idstring否null

現(xiàn)在可以通過傳入id的方式來使用組件了：

const noteId =  123  
<Note dataId={noteId} /> 

• 請(qǐng)注意，api中的兩個(gè)屬性都是非必填的，因?yàn)椴恢烙脩魰?huì)傳入哪個(gè)屬性，為了程序的嚴(yán)謹(jǐn)性，組件內(nèi)部應(yīng)當(dāng)校驗(yàn)兩個(gè)參數(shù)都不傳的情況，并通過拋出錯(cuò)誤告訴調(diào)用者。

這是組件設(shè)計(jì)的一個(gè)技巧，通過支持多種數(shù)據(jù)源使得調(diào)用更加簡(jiǎn)單。但是這種設(shè)計(jì)也有其弊端所在，如果這種兼容性的擴(kuò)展過多會(huì)使得組件的內(nèi)部邏輯變得復(fù)雜，也會(huì)使得api變得難于理解，因此，對(duì)于兼容性的api擴(kuò)展要謹(jǐn)慎，不可過量。

3. 兼容不同模式

組件的使用一如既往的優(yōu)雅、簡(jiǎn)單，但是現(xiàn)在又有用戶提出新的需求了：因?yàn)樵摻M件是支持閱讀與編輯兩種模式的，在使用時(shí)，對(duì)于他人的筆記是不可編輯的，能否在指定的場(chǎng)景下只支持一種閱讀模式?

筆記組件由于內(nèi)部支持了兩種模式，既支持閱讀，也支持編輯。因此調(diào)用者只想使用一種模式也是合理的。于是，我們繼續(xù)擴(kuò)展組件的api：

屬性說明類型是否必填默認(rèn)值mode模式，數(shù)組的第一項(xiàng)作為初始模式，該參數(shù)不可為空數(shù)組array否[ write , read ]

現(xiàn)在，對(duì)于只想使用閱讀模式的用戶，可以這么調(diào)用：

const note = {} 
const mode = [ read ] 
<Note data={note} mode={mode} /> 

 在設(shè)計(jì)api時(shí)，我們?cè)跐M足需求的前提下，支持了更多情況。首先，使用者也可能只使用編輯模式，因?yàn)閙ode參數(shù)是支持隨意組合各種模式的，因此這種情況也能滿足。另外，如果組件以后擴(kuò)展了更多模式，該api仍然能滿足需求，只需要為mode數(shù)組增加更多的模式項(xiàng)即可。這里有一個(gè)更佳的設(shè)計(jì)是，當(dāng)使用多個(gè)模式時(shí)，確定哪個(gè)模式作為初始模式也是有必要的，因此，將mode數(shù)組的第一項(xiàng)作為多模式下的初始模式，既滿足了需求，又達(dá)到了api設(shè)計(jì)最小化的原則。

現(xiàn)在，我們對(duì)用戶的需求進(jìn)行了擴(kuò)展，不僅支持只使用閱讀模式，還支持各種模式任意組合和初始模式，但是這還不夠，組件的設(shè)計(jì)者應(yīng)當(dāng)針對(duì)需求想到更長(zhǎng)遠(yuǎn)的情況，針對(duì)這個(gè)例子，我們還可以為組件擴(kuò)展一個(gè)模式改變的事件，讓調(diào)用者可以捕捉到筆記組件從閱讀 -> 編輯或編輯 -> 閱讀(隨著模式的擴(kuò)展，這種組合會(huì)更多)切換的時(shí)機(jī)：

事件說明回調(diào)參數(shù)modeChange模式切換時(shí)觸發(fā)(from: string, to: string) from表示切換前的模式，to表示切換后的模式

調(diào)用者可能在捕捉到模式切換事件時(shí)，做一些特定的工作：

function handleModeChange(from, to) { 
  // ... 
} 
<Note onModeChange={handleModeChange}  /> 

 4. 更多的支持

在編輯器中編輯筆記是html或markdown類型的，筆記組件支持將筆記導(dǎo)出為一個(gè)PDF文檔。因此，設(shè)計(jì)時(shí)我們可以將組件的一些能力抽象為api，再次擴(kuò)展組件的api：

方法說明參數(shù)exportPDF導(dǎo)出筆記為PDF文件-toggleFullscreen切換全屏顯示(value: boolean) 是否全屏展示

組件設(shè)計(jì)時(shí)，我們可以將可預(yù)見范圍內(nèi)的組件的能力設(shè)計(jì)為api，需要注意的，方法的參數(shù)與返回值也是api的一部分，應(yīng)當(dāng)謹(jǐn)慎設(shè)計(jì)。

除了擴(kuò)展組件的能力外，我們還可以擴(kuò)展組件的視圖。注意到閱讀按鈕右側(cè)的工具欄了嗎?我們假設(shè)這部分的視圖不屬于筆記組件，是通過api擴(kuò)展而渲染出來的，這就是組件的子視圖設(shè)計(jì)，在web前端的組件化中，稱為插槽。我們可以為筆記組件擴(kuò)展一個(gè)工具欄的插槽：

插槽說明參數(shù)toolbar工具欄子視圖{ data }

當(dāng)調(diào)用者想要擴(kuò)展筆記組件的工具欄時(shí)，可以這么使用：

const note = {} 
<Note data={note}> 
    <MyToolbar /> 
</Note> 

 這樣，調(diào)用者就可以根據(jù)自己的需求，在工具欄渲染自己想要的內(nèi)容了。

三、組件設(shè)計(jì)四要素

上述案例講述了組件設(shè)計(jì)的整個(gè)流程，通過分析用戶的需求(或未來可能出現(xiàn)的需求)，一步一步地設(shè)計(jì)出了一個(gè)復(fù)用度高、擴(kuò)展性好的組件。如果你是一個(gè)組件設(shè)計(jì)的新手，你應(yīng)該如何去思考、去設(shè)計(jì)一個(gè)優(yōu)良的組件呢?

1. 先設(shè)計(jì)，后實(shí)現(xiàn)

我們通篇在討論組件的設(shè)計(jì)，但是實(shí)際操作時(shí)，很多朋友會(huì)通過邊實(shí)現(xiàn)邊設(shè)計(jì)的方式來完成一個(gè)組件的制作，這是不合理的，因?yàn)樽陨砟芰εc眼界的限制，實(shí)現(xiàn)可能會(huì)干擾你的設(shè)計(jì)，對(duì)于以下兩個(gè)經(jīng)典矛盾，希望讀者能選擇后者，以追求合理性為重。

這樣實(shí)現(xiàn)比較方便，不如將這個(gè)參數(shù)拋出讓用戶傳進(jìn)來吧!

這樣設(shè)計(jì)比較合理，雖然實(shí)現(xiàn)難度可能會(huì)比較高，但我可以通過文檔學(xué)習(xí)、求問他人的方式來實(shí)現(xiàn)它，或者直接讓他人來實(shí)現(xiàn)。

**提出問題比解決問題更難。**設(shè)計(jì)難于實(shí)現(xiàn)，你應(yīng)當(dāng)花70%的時(shí)間來設(shè)計(jì)而不是用來實(shí)現(xiàn)。有的設(shè)計(jì)者甚至不參與實(shí)現(xiàn)，設(shè)計(jì)者與實(shí)現(xiàn)者的身份也是隨時(shí)在轉(zhuǎn)換的，善于思考的實(shí)現(xiàn)者本身就是設(shè)計(jì)者。

2. 組件設(shè)計(jì)四要素

• 屬性
• 方法
• 事件
• 子視圖(插槽)

上述的案例基本涵蓋了這四個(gè)要素，這四要素共同組成了組件的api。需要注意的，除了基本的四要素外，我們還需要注意這些也是組件api的一部分：

• 屬性的類型、是否必填、默認(rèn)值(屬性類型確定后不再變化)
• 方法的參數(shù)、返回值(需要考慮變化的情況)
• 事件回調(diào)函數(shù)的參數(shù)
• 插槽可獲取到的局部參數(shù)

在設(shè)計(jì)時(shí)，應(yīng)當(dāng)小心謹(jǐn)慎面對(duì)每一個(gè)api的要素，哪一個(gè)環(huán)節(jié)出現(xiàn)了設(shè)計(jì)缺陷，對(duì)于調(diào)用者都是如鯁在喉。

四、終極思維：面向?qū)ο?/span>

盡管我們通過一系列的理論講述了組件設(shè)計(jì)的方法，但是對(duì)于初學(xué)者而言，仍然難以設(shè)計(jì)出一個(gè)優(yōu)良的組件，設(shè)計(jì)一個(gè)優(yōu)良的組件需要大量的經(jīng)驗(yàn)，初學(xué)者往往考慮不全面，或因?qū)π枨蟮牟涣私?，無法預(yù)知未來的變化。

盡管如此，初學(xué)者仍然要耐心學(xué)習(xí)組件的設(shè)計(jì)，不積跬步無以至千里，經(jīng)過一段時(shí)間的積累，我總結(jié)了一個(gè)設(shè)計(jì)組件的終極思維，將面向?qū)ο蟮乃枷胗糜诮M件設(shè)計(jì)，將會(huì)事半功倍。

在開發(fā)領(lǐng)域，學(xué)會(huì)思考比埋頭干活重要。我們將這個(gè)理論用于組件設(shè)計(jì)中，如何通過面向?qū)ο蟮乃季S來設(shè)計(jì)一個(gè)組件呢?

雖然我們強(qiáng)調(diào)使用面向?qū)ο蟮乃季S來設(shè)計(jì)組件，但仿佛面向?qū)ο笏季S比組件設(shè)計(jì)更高深，我們當(dāng)然不會(huì)推薦大家用更加晦澀的理論來指導(dǎo)組件的設(shè)計(jì)，這里，我們將面向?qū)ο髷M人化，提取出一個(gè)自然世界聯(lián)想法的思維方法。

下面我們就用這種方法，來設(shè)計(jì)一個(gè)快遞小哥的組件：

首先，快遞小哥有他的基本信息，這是該組件的屬性，基本信息中包含了他的任職單位、工作年限、姓名、聯(lián)系方式等等。此外，快遞小哥有一些特有的行為，例如送快遞、接收包裹等，我們可以將這部分抽取為組件的方法，比如我們調(diào)用快遞小哥的接收包裹方法，該方法有兩個(gè)參數(shù)，第一個(gè)參數(shù)是我要寄的東西即包裹，第二個(gè)參數(shù)是快遞單，描述了寄送相關(guān)的信息。除了基本信息和一些行為外，快遞小哥組件還有一些特有的事件，當(dāng)我們的包裹到了時(shí)，他會(huì)打電話給我們，這里，組件拋出了一個(gè)快遞到達(dá)的事件，事件的參數(shù)是快遞單和包裹，快遞單描述了包裹的送達(dá)信息，包裹是快遞單中描述的接收人的東西。最后，快遞小哥組件有沒有子視圖呢?有。快遞小哥組件除了被我們普通用戶調(diào)用外，還會(huì)被快遞公司所調(diào)用，不同的快遞公司會(huì)以不同的方式來包裝快遞小哥(例如通過不同服裝不同logo的方式)，因此，快遞公司在調(diào)用該組件時(shí)，會(huì)將快遞小哥的服裝傳入一個(gè)名為裝束的子視圖中，這樣，不同公司的快遞小哥就有不同的裝束了。

你可以使用自然世界聯(lián)想法來思考一切關(guān)于面向?qū)ο笈c組件化相關(guān)的問題，只要計(jì)算機(jī)世界仍然是人構(gòu)建的，我們就仍然可以按照自然世界的規(guī)則來感知計(jì)算機(jī)世界。

二進(jìn)制世界從來不是冰冷、無情的，每一個(gè)二進(jìn)制串都融入了編碼人的思維模式、價(jià)值觀。

五、最后

重新回到開篇的問題，為什么說當(dāng)今的web前端開發(fā)已變成web客戶端開發(fā)呢?因?yàn)榻M件化是所有客戶端開發(fā)的核心概念，只要這個(gè)端大部分的時(shí)間在做組件抽象的工作，我們就可以認(rèn)為自己在從事客戶端開發(fā)。

最后，組件化不是銀彈，不能為你解決任何實(shí)際問題，它只是一種思維方式。