如何寫一個優秀的組件

我以前用angularjs，當時的angular 1的版本，數據雙向綁定成爲一個亮點，也是人們詬病至今的一個問題。直到我遇到了react，很是欣賞react組件化編程的思路。可使得複雜的大型應用碎片化，而又能夠很好的組織在一塊兒，便於管理。今天分享一下對於寫組件的一些見解和心得。代碼演示仍是以react爲主。

如何定義一個組件是優秀的，或者咱們一般意義上認爲的好的，咱們從如下幾個方面展開討論。

單一響應 - 「Single responsibility」

說白了，就是組件儘可能只幹一件事。提及來容易作起來卻很不容易。咱們每每喜歡或者習慣不斷的擴展組件的響應，最後變成一個『胖』組件-他能完成全部事

咱們爲何要要求組件單一響應，其實不論咱們的組件用來作什麼-加載一個圖片，顯示一個列表，發起一個ajax請求，咱們都但願在改變組件的時候變得簡單可控。

來看下

例如：咱們須要一個獲取數據的組件

• server url 發生變化
• 響應格式發生變化
• 你想換一個ajax庫
• 或者是其它改變

例如：咱們寫一個table組件

• 限制table中展現的行數
• 當沒有數據的時候展現 『暫無數據』
• 增長排序功能
• 增長分頁功能
• 或者其它需求

若是咱們沒法用一個單一響應組件知足全部需求，就須要拆分紅更細小的組件來完成任務。

這裏想一下一個『胖』組件產生的理由：

• 在我開發組件的時候不須要去結構化的細分需求
• 無需建立不少組件，也就無需管理子組件之間的關係
• 也就不用建立不少的props和event保持組件的通訊

請自問：請問你寫一個頁面或者組件，他須要彈窗，那麼你的彈窗是寫在組件裏面，仍是另外寫一個彈窗組件？

看下這裏的組件怎麼拆分

封裝- 「Encapsulated」

封裝的目的和好處也很是簡單，就是解耦。

鬆耦合的好處：

• 當組件改變時不會影響其餘組件
• 任何一個組件均可以被即時替換
• 提升單一組件在系統的可複用性
• 獨立組件很方便被測試
• 隱藏組件信息

可組合-"Composable"

既然咱們但願組件單一響應，封裝，那麼必然致使複雜功能的難以實施，那麼咱們必然要求組件能夠被靈活的組合拼裝。來知足複雜應用

可重用-"Reusable"

代碼寫一次能夠被應用到多個場景，而不須要進行二次開發，作到上面3條，這一條天然達成

純淨-「Pure」 or 「Almost-pure」

純淨的組件的意思被單一誘因改變

改一下變得純淨

舉一個實際的例子

可測試-「Testable」 and 「Tested」

語義化-"Meaningful"

<DatePicker>, <GridItem>, <Application>, <Header>

組件語義化就是最好的文檔

One word - one concept

總結：

一個可靠的組件能夠履行一個職責，隱藏其內部結構，並提供有效的屬性和接口控制其行爲。

怎麼作：

一開始就寫一個優秀的組件是很難的，緣由不少，根本緣由是咱們一開始沒法想清楚全部的環節，不是偷懶，而是可獲取的資料太少。那麼咱們應該怎麼作-迭代或者優化

責任心或者叫工匠精神-由於不多有人喜歡不斷翻老代碼，除非他頗有可能在之後用到，因此一邊培養工匠精神，一邊趁熱打鐵，在最快的時間不斷去完善本身的代碼，我通常會在發佈後，就上次的失誤，改一些代碼，固然要在可控的狀況下，而後把他放到二期催促測試迴歸測試，本身也要充分測試。

聽取他人的意見，codereview很是合適，幫助本身的同時也幫助別人提高。review的第一件事就是看你的代碼是否語義化，沒人願意幫你review代碼只有一個緣由，你的代碼可讀性太差。須要提高了。