簡單說幾句，聊聊如何設計組件？
一、寫在前面
現今的web開發通過前后端分離的技術拆分為了web后端開發與web前端開發，值得指出的是，web前端開發早已不是傳統意義上的開發模式了，轉而變成了web客戶端開發，有過客戶端開發經驗的同學應該知道這兩者間的差別，客戶端開發關注的是：
- 應用的生命周期
- 組件化
- 開發模式與打包方法
組件化是客戶端開發最重要的內容，設計一套復用度高、擴展性好的組件系統，可以顯著提高開發效率，并且可以減少后期的維護成本。
二、一個筆記組件的設計案例
就以我正在使用的筆記app為例，上圖展示的筆記的閱讀與書寫區域，如何將這個區域抽象為一個組件呢?讓我們一步一步來分析。
1. 最簡api
我們為該組件取個名字(取名很重要)，就叫Note吧。不管是在閱讀狀態還是在編輯狀態，該組件都要展示筆記的內容，因為筆記對象應該通過組件的接口傳入進來，因為我們為該組件設計第一個api：
屬性說明類型是否必填data筆記對象數據object是
接下來，我們簡單使用一下這個組件：
為了兼容vue與react的讀者，本頁面均使用JSX語法
- const note = {
- title: 如何制作一個組件？.md ,
- content:
- }
這樣，一個最簡api的筆記組件就搞定了，它的接口非常簡單，只需要提供一個data屬性，就可以展示出筆記內容，并且可以點擊編輯進入書寫狀態。
一般而言，如果沒有更多的需求的話，我們的筆記組件設計到這里也就可以了。**在設計組件時，務必遵循最小化原則，即盡可能少地拋出接口。**因為使用組件的用戶可能有很多，一旦組件作者不小心拋出了一個不合理的接口，以后想要修改就幾乎不可能了(只能通過標記過時的方法提醒用戶，但這種做法往往是無奈之舉)。
2. 滿足數據獲取的多種情況
現在，組件的使用者已經可以通過很簡潔的api使用這個筆記組件了，但是現在問題來了：有的組件使用者只拿到了筆記的id，想要通過直接傳入id的方式使用組件。
此時，作為組件作者，我們評估了這個需求是合理的，于是，我們擴展了筆記組件的api：
屬性說明類型是否必填默認值data筆記對象object否nulldataId筆記對象idstring否null
現在可以通過傳入id的方式來使用組件了：
- const noteId = 123
- <Note dataId={noteId} />
- 請注意，api中的兩個屬性都是非必填的，因為不知道用戶會傳入哪個屬性，為了程序的嚴謹性，組件內部應當校驗兩個參數都不傳的情況，并通過拋出錯誤告訴調用者。
這是組件設計的一個技巧，通過支持多種數據源使得調用更加簡單。但是這種設計也有其弊端所在，如果這種兼容性的擴展過多會使得組件的內部邏輯變得復雜，也會使得api變得難于理解，因此，對于兼容性的api擴展要謹慎，不可過量。
3. 兼容不同模式
組件的使用一如既往的優雅、簡單，但是現在又有用戶提出新的需求了：因為該組件是支持閱讀與編輯兩種模式的，在使用時，對于他人的筆記是不可編輯的，能否在指定的場景下只支持一種閱讀模式?
筆記組件由于內部支持了兩種模式，既支持閱讀，也支持編輯。因此調用者只想使用一種模式也是合理的。于是，我們繼續擴展組件的api：
屬性說明類型是否必填默認值mode模式，數組的第一項作為初始模式，該參數不可為空數組array否[ write , read ]
現在，對于只想使用閱讀模式的用戶，可以這么調用：
- const note = {}
- const mode = [ read ]
- <Note data={note} mode={mode} />
在設計api時，我們在滿足需求的前提下，支持了更多情況。首先，使用者也可能只使用編輯模式，因為mode參數是支持隨意組合各種模式的，因此這種情況也能滿足。另外，如果組件以后擴展了更多模式，該api仍然能滿足需求，只需要為mode數組增加更多的模式項即可。這里有一個更佳的設計是，當使用多個模式時，確定哪個模式作為初始模式也是有必要的，因此，將mode數組的第一項作為多模式下的初始模式，既滿足了需求，又達到了api設計最小化的原則。
現在，我們對用戶的需求進行了擴展，不僅支持只使用閱讀模式，還支持各種模式任意組合和初始模式，但是這還不夠，組件的設計者應當針對需求想到更長遠的情況，針對這個例子，我們還可以為組件擴展一個模式改變的事件，讓調用者可以捕捉到筆記組件從閱讀 -> 編輯或編輯 -> 閱讀(隨著模式的擴展，這種組合會更多)切換的時機：
事件說明回調參數modeChange模式切換時觸發(from: string, to: string) from表示切換前的模式，to表示切換后的模式
調用者可能在捕捉到模式切換事件時，做一些特定的工作：
- function handleModeChange(from, to) {
- // ...
- }
- <Note onModeChange={handleModeChange} />
4. 更多的支持
在編輯器中編輯筆記是html或markdown類型的，筆記組件支持將筆記導出為一個PDF文檔。因此，設計時我們可以將組件的一些能力抽象為api，再次擴展組件的api：
方法說明參數exportPDF導出筆記為PDF文件-toggleFullscreen切換全屏顯示(value: boolean) 是否全屏展示
組件設計時，我們可以將可預見范圍內的組件的能力設計為api，需要注意的，方法的參數與返回值也是api的一部分，應當謹慎設計。
除了擴展組件的能力外，我們還可以擴展組件的視圖。注意到閱讀按鈕右側的工具欄了嗎?我們假設這部分的視圖不屬于筆記組件，是通過api擴展而渲染出來的，這就是組件的子視圖設計，在web前端的組件化中，稱為插槽。我們可以為筆記組件擴展一個工具欄的插槽：
插槽說明參數toolbar工具欄子視圖{ data }
當調用者想要擴展筆記組件的工具欄時，可以這么使用：
- const note = {}
- <Note data={note}>
- <MyToolbar />
- </Note>
這樣，調用者就可以根據自己的需求，在工具欄渲染自己想要的內容了。
三、組件設計四要素
上述案例講述了組件設計的整個流程，通過分析用戶的需求(或未來可能出現的需求)，一步一步地設計出了一個復用度高、擴展性好的組件。如果你是一個組件設計的新手，你應該如何去思考、去設計一個優良的組件呢?
1. 先設計，后實現
我們通篇在討論組件的設計，但是實際操作時，很多朋友會通過邊實現邊設計的方式來完成一個組件的制作，這是不合理的，因為自身能力與眼界的限制，實現可能會干擾你的設計，對于以下兩個經典矛盾，希望讀者能選擇后者，以追求合理性為重。
這樣實現比較方便，不如將這個參數拋出讓用戶傳進來吧!
這樣設計比較合理，雖然實現難度可能會比較高，但我可以通過文檔學習、求問他人的方式來實現它，或者直接讓他人來實現。
**提出問題比解決問題更難。**設計難于實現，你應當花70%的時間來設計而不是用來實現。有的設計者甚至不參與實現，設計者與實現者的身份也是隨時在轉換的，善于思考的實現者本身就是設計者。
2. 組件設計四要素
- 屬性
- 方法
- 事件
- 子視圖(插槽)
上述的案例基本涵蓋了這四個要素，這四要素共同組成了組件的api。需要注意的，除了基本的四要素外，我們還需要注意這些也是組件api的一部分：
- 屬性的類型、是否必填、默認值(屬性類型確定后不再變化)
- 方法的參數、返回值(需要考慮變化的情況)
- 事件回調函數的參數
- 插槽可獲取到的局部參數
在設計時，應當小心謹慎面對每一個api的要素，哪一個環節出現了設計缺陷，對于調用者都是如鯁在喉。
四、終極思維：面向對象
盡管我們通過一系列的理論講述了組件設計的方法，但是對于初學者而言，仍然難以設計出一個優良的組件，設計一個優良的組件需要大量的經驗，初學者往往考慮不全面，或因對需求的不了解，無法預知未來的變化。
盡管如此，初學者仍然要耐心學習組件的設計，不積跬步無以至千里，經過一段時間的積累，我總結了一個設計組件的終極思維，將面向對象的思想用于組件設計，將會事半功倍。
在開發領域，學會思考比埋頭干活重要。我們將這個理論用于組件設計中，如何通過面向對象的思維來設計一個組件呢?
雖然我們強調使用面向對象的思維來設計組件，但仿佛面向對象思維比組件設計更高深，我們當然不會推薦大家用更加晦澀的理論來指導組件的設計，這里，我們將面向對象擬人化，提取出一個自然世界聯想法的思維方法。
下面我們就用這種方法，來設計一個快遞小哥的組件：
首先，快遞小哥有他的基本信息，這是該組件的屬性，基本信息中包含了他的任職單位、工作年限、姓名、聯系方式等等。此外，快遞小哥有一些特有的行為，例如送快遞、接收包裹等，我們可以將這部分抽取為組件的方法，比如我們調用快遞小哥的接收包裹方法，該方法有兩個參數，第一個參數是我要寄的東西即包裹，第二個參數是快遞單，描述了寄送相關的信息。除了基本信息和一些行為外，快遞小哥組件還有一些特有的事件，當我們的包裹到了時，他會打電話給我們，這里，組件拋出了一個快遞到達的事件，事件的參數是快遞單和包裹，快遞單描述了包裹的送達信息，包裹是快遞單中描述的接收人的東西。最后，快遞小哥組件有沒有子視圖呢?有。快遞小哥組件除了被我們普通用戶調用外，還會被快遞公司所調用，不同的快遞公司會以不同的方式來包裝快遞小哥(例如通過不同服裝不同logo的方式)，因此，快遞公司在調用該組件時，會將快遞小哥的服裝傳入一個名為裝束的子視圖中，這樣，不同公司的快遞小哥就有不同的裝束了。
你可以使用自然世界聯想法來思考一切關于面向對象與組件化相關的問題，只要計算機世界仍然是人構建的，我們就仍然可以按照自然世界的規則來感知計算機世界。
二進制世界從來不是冰冷、無情的，每一個二進制串都融入了編碼人的思維模式、價值觀。
五、最后
重新回到開篇的問題，為什么說當今的web前端開發已變成web客戶端開發呢?因為組件化是所有客戶端開發的核心概念，只要這個端大部分的時間在做組件抽象的工作，我們就可以認為自己在從事客戶端開發。
最后，組件化不是銀彈，不能為你解決任何實際問題，它只是一種思維方式。
