日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

 一、寫在前面

創(chuàng)新互聯(lián)長期為上1000+客戶提供的網(wǎng)站建設服務，團隊從業(yè)經(jīng)驗10年，關(guān)注不同地域、不同群體，并針對不同對象提供差異化的產(chǎn)品和服務；打造開放共贏平臺，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為大埔企業(yè)提供專業(yè)的網(wǎng)站設計、網(wǎng)站制作，大埔網(wǎng)站改版等技術(shù)服務。擁有十載豐富建站經(jīng)驗和眾多成功案例,為您定制開發(fā)。

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

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

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

二、一個筆記組件的設計案例

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

1. 最簡api

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

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

接下來，我們簡單使用一下這個組件：

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

 
 
 
 

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

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

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

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

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

此時，作為組件作者，我們評估了這個需求是合理的，于是，我們擴展了筆記組件的api：

屬性說明類型是否必填默認值data筆記對象object否nulldataId筆記對象idstring否null

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

 
 
 
 

  
  
  
  
const noteId =  123  
  
  
  
  
 
 
 
 
 

• 請注意，api中的兩個屬性都是非必填的，因為不知道用戶會傳入哪個屬性，為了程序的嚴謹性，組件內(nèi)部應當校驗兩個參數(shù)都不傳的情況，并通過拋出錯誤告訴調(diào)用者。

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

3. 兼容不同模式

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

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

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

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

 
 
 
 

  
  
  
  
const note = {} 
  
  
  
  
const mode = [ read ] 
  
  
  
  
 
 
 
 
 

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

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

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

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

 
 
 
 

  
  
  
  
function handleModeChange(from, to) { 
  
  
  
  
  // ... 
  
  
  
  
} 
  
  
  
  
 
 
 
 
 

 4. 更多的支持

在編輯器中編輯筆記是html或markdown類型的，筆記組件支持將筆記導出為一個PDF文檔。因此，設計時我們可以將組件的一些能力抽象為api，再次擴展組件的api：

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

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

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

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

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

 
 
 
 

  
  
  
  
const note = {} 
  
  
  
  
 
  
  
  
  
     
  
  
  
  
 
 
 
 
 

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

三、組件設計四要素

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

1. 先設計，后實現(xiàn)

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

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

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

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

2. 組件設計四要素

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

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

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

在設計時，應當小心謹慎面對每一個api的要素，哪一個環(huán)節(jié)出現(xiàn)了設計缺陷，對于調(diào)用者都是如鯁在喉。

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

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

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

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

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

下面我們就用這種方法，來設計一個快遞小哥的組件：

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

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

二進制世界從來不是冰冷、無情的，每一個二進制串都融入了編碼人的思維模式、價值觀。

五、最后

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

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