再也不 「封裝」 組件

世事總不能盡如人意。

就算強如 NG-ZORRO，雖然 99% 的狀況下已經足夠豐富，足夠強大，足夠恰當，但總有 %1 的狀況，你會但願它能這樣、或者那樣就行了。

不少項目組都有 「封裝」 組件的優良傳統。理由有技術層面的，也有非技術層面的。我之前也沒少幹這事兒。有的時候是 nz-select 變成了 my-select、nz-date-picker 變成了 my-date-picker；有的時候是它們通通變成了 my-form-edit-control。

最後，咱們得到了好處，也付出沉重的代價：

• 組件使用起來更加簡單，但更加不靈活；
• 組件 API 更加通用，但到最後程序猿每每不得不學習兩套API；
• 組件功能更加強大，但與原來的組件有哪些微妙的差異又很讓人迷惑，到底該用哪一個又總要糾結；
• 有時候能有效屏蔽破壞性更新，但慢慢就開始阻礙進步……

怎麼破？

輕量級、裝飾模式、單一職責

這是軟件領域最美妙的幾個詞兒之一，並且它們很適合用來形容 Angular 的指令。

例如，若是咱們但願卡片組件能自適應頁面的高度，就能夠寫一個名爲 nsAutoHeightCard 的指令 源碼 demo，將其 「裝飾」 到 nz-card 組件上，就實現了自適應頁面高度的卡片。

<nz-card nsAutoHeightCard nzTitle="自適應高度卡片"> 
  <p>Card content</p> 
</nz-card>

相似的，增長 nsFlipH 或 nsFlipV 指令便可實現 3D 水平或豎直翻轉的動效：

DRY

NG-ZORRO 做爲組件庫，保持組件模型的簡單、直接沒有問題。但咱們在實際的工程實踐中，須要更大程度地遵循 DRY(Don’t Repeat Yourself) 原則，以表單驗證爲例：

• 對於必填項等常規表單驗證顯示錯誤信息的功能，應該統一處理，而不是在每一個表單中將錯誤信息重複一遍。
• 既然已經在 FormGroup 對象中配置了驗證條件，表單組件最好能根據這些條件自動配置驗證視覺反饋，而不用再在表單組件中重複配置 nzRequired 和 nzHasFeedback。

咱們能夠經過無腦統一給每一個組件增長 nsAutoFeedback 和 nsErrorTip 指令 源碼1 源碼2 demo，就能夠將上述那些繁瑣枯燥還易錯的工做所有自動完成，甚至還能自動爲標籤和編輯組件增長 nzFor 和 id 屬性：

<nz-form-item *nsAutoFeedback>
  <nz-form-label [nzSpan]="8">用戶名</nz-form-label>
  <nz-form-control nsErrorTip nzSpan="16">
    <input nz-input formControlName="userText" />
  </nz-form-control>
</nz-form-item>

更多細節請參考所有源碼

總結

有實力 / 從零打造 / 組件庫要否則 / 輕量裝飾 / 很舒服