组件化:搭建系统、智慧活动
目的:内聚性、耦合性、避免因业务引起重复劳动、协同合作、提高可维护性
组件化前提:制定标准,接触耦合
第一代:YUI
太过于学院派。要求每个用这个程序员熟悉整套UI规范和使用规范。就是要熟悉YUI的CSS,HTML,JS,这样才能用非常爽
第二代 ExtJS
ExtJS是踩着YUI的尸体走过来的,extjs比YUI进步在那儿呢,首先它表面上有一套漂亮的UI。这个实质上就是你不用写CSS了,它帮你写好了。另外你HTML也不用写了,它也帮你写好了。这不对啊,前端页面怎么可以没有HTML和CSS呢,extjs都帮你封装到js里了
extjs用是很简单,定制的话,还是改错一处,全局。
被边缘化
第三代:web component
shadow dom/custom element/template/import
这规范到不成熟,到处是坑
the end...
当然,组件化的时代已经开启,为了填原生的坑,已经有无数勇士已经又踩着前者的尸体冲上来了
他们是:
Angular Directives
Ember Components
React Components
KnockoutJS Components
Vue.js Components
Backbone Components
CanJS Components
Famous Components
Anything.JS Components?
贺师俊:
之所以一直说对custom element持谨慎态度,是因为正如本问题所表达出来的,大多数工程师对组件如何设计划分是缺乏经验的。相对来说基于 is 属性对原有html元素做扩展比较不容易出偏。
组件设计说到底是要做某种抽象。难就难在这种抽象要考虑很多的因素,比如适应UI设计师的建模、工程上的可维护性要求、常见用例和边缘用例的矛盾、自定义组件和标准html元素的穿插交互、适应将来需求变化发展的可扩展性和可定制性……其中很多点是在开始设计开发时很难确定的,或者随着业务发展经常会变化。这就是为什么组件领域比其他技术领域更容易出现抽象泄漏的悲剧。