再也不 “封装” 组件

世事总不能尽如人意。

就算强如 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>

更多细节请参考所有源码

总结

有实力 / 从零打造 / 组件库要否则 / 轻量装饰 / 很舒服