不再 “封装” 组件

世事总不能尽如人意。

就算强如 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 组件上，就实现了自适应页面高度的卡片。

 
  
Card content
 

类似的，增加 nsFlipH 或 nsFlipV 指令即可实现 3D 水平或竖直翻转的动效：

DRY

NG-ZORRO 作为组件库，保持组件模型的简单、直接没有问题。但我们在实际的工程实践中，需要更大程度地遵循 DRY(Don’t Repeat Yourself) 原则，以表单验证为例：

• 对于必填项等常规表单验证显示错误信息的功能，应该统一处理，而不是在每个表单中将错误信息重复一遍。
• 既然已经在 FormGroup 对象中配置了验证条件，表单组件最好能根据这些条件自动配置验证视觉反馈，而不用再在表单组件中重复配置 nzRequired 和 nzHasFeedback。

我们可以通过无脑统一给每个组件增加 nsAutoFeedback 和 nsErrorTip 指令 源码1 源码2 demo，就可以将上述那些繁琐枯燥还易错的工作全部自动完成，甚至还能自动为标签和编辑组件增加 nzFor 和 id 属性：

  用户名
  
    
  

更多细节请参考全部源码

总结

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