基于原生HTML的UI组件开发

　　本文属于波澜不惊，平铺直叙版本。如果想看有激情有思想的版本，可以去ISUX官博：“顺势而为，HTML发展与UI组件设计进化”，多多留言哈。

　　一、基于HTML开发组件的设计思想

　　要想知道基于原生的HTML进行UI组件开发是什么鬼，您可以狠狠地点击这里：基于原生的HTML UI组件体验demo

　　点击上面的demo, 进入一个平凡的静态页面，引入眼帘的是一个普通的表单，里面的UI都是系统默认的，HTML功能也是原生的。

　　例如：

• 　　title提示

• 　　选择日期

• 　　点击提交的表单验证

　　UI虽然原始，但是功能却很健全。

　　例如：

• 　　男女款式、城市以及运费险对价格的影响

• 　　表单提交事件

　　下面，就是奇迹出现了，点击demo页面(下图所示)的按钮进行某项目UI组件资源的加载和初始化：

　　结果，一瞬间，上面原始粗糙的界面一下子变成了这样子：

　　妥妥的丑小鸭变成了白天鹅，包括之前原生的HTML功能。

　　例如：

• 　　title提示

• 　　选择日期

• 　　点击提交的表单验证

　　而，最最重要，和最最神奇的事情是：我们仅仅是引入了UI组件的一些CSS和JS，对，仅仅是引入和一点初始化，没有动之前一点点一丝丝的业务JS. 但是，之前的各种交互功能，却完全不受影响，反而体验更上两层楼!

　　请看下面的gif截图演示：

　　之所以这里的UI组件可以和业务相关JavaScript完全分离，同时可以无缝对接。就是因为设计理念上是基于原生的HTML实现的，让UI组件回归其本质或者说本职作用——UI.

　　二、基于原生HTML的UI组件开发

　　解决2个疑问：

1. 　为何可以基于原生HTML进行UI组件开发?
2. 　如何基于原生HTML进行UI组件开发?

　　1. 为何可以基于原生HTML进行UI组件开发?

　　HTML中自带的很多原生的UI表现，UI组件的UI表现本质上是类似的，差别仅仅在于长相的粗糙和精致。

　　举个例子，title提示。浏览器默认使用title属性，长这样：

　　而设计师设计的tips组件是小黑风格，如下：

　　这两者其实是一个东西，作用是一样的，差别仅仅在于——UI. 因此，我们完全可以基于原生的title属性实现我们的tips提示效果。利用相同的本质，改变的仅仅是呈现的样子。

　　再举个更有意思的例子，表单验证。在HTML5中，表单默认内置验证，基于type, required, pattern, max, min等HTML原生属性，且自带UI(下图是win下Chrome效果，其他系统其他浏览器长相不一样):

　　下图则是team决定采用的UI形式：

　　同样的，验证的本质都是类似的，交互的形式也是类似的，不一样的仅仅是UI. 因此，我们完全可以基于原生的HTML验证规则实现我们的表单验证效果。利用相同的本质，改变的仅仅是呈现的样子。

　　其他很多UI组件都是类似的。

　　当我们希望改变的仅仅是相貌的时候，重复利用之前的灵魂难道不是最合理的策略吗?

　　2. 如何基于原生HTML进行UI组件开发?

　　有2个要点：① API参数直接取自HTML; ② 回调直接trigger原生事件;

　　我们拿上面提过的日期时间选择器举例说明下。

　　日期选择器，主流实现基本上是这样的：

<br/>

new DatePicker($("#date"), {
  type: "date",
  initDate: ..,
  beginDate: ..,
  endDate: ..,
  onSelected: $.noop
});

<br/>　　API参数，事件的回调全部源自JS参数。

　　而面向HTML的设计思想下的实现则是：

<br/>

new DateTime($("[type=date]");

<br/>　　API参数全部取自HTML，JS代码仅仅就是全局初始化(一次覆盖所有时间类控件)。其中HTML中的type属性对应JS中的type API, value属性值对应initDate值, min/max分别对应beginDate/endDate. 至于onSelected回调，则是通过trigger input框原生的change时间实现。

　　于是，其他前端小伙伴在开发的时候，就可以按照原生的HTML属性和事件来开发就可以了，从而实现业务JS和UI组件基于0成本的无缝对接。

　　三、面向HTML的UI组件开发的好处

1. 　语义化，可访问性，SEO等;

2. 　学习成本低;

3. 　专注HTML控件本身，而不是组件;

4. 　可以一次性全局处理;

　　1. 语义化，可访问性

　　毕竟是基于原生HTML来开发的，这一块必定杠杠的。

　　2. 更低的学习成本

　　不需要记住千差万别的JS API名称，记住标准的HTML5属性即可，反过来对一些前端开发同学的HTML学习还起到了帮助作用。

　　而学习成本低对于跨团队合作非常有帮助。其他团队同学乐于使用你的东西，介入快，实现效果好，大家都开心。反之，API千差万别，每次使用都要去翻文档，肯定影响合作。

　　不过，实践下来，有一点学习成本我没考虑到，就是转换思维方式的学习成本。实际上只要面向元素的HTML元素开发就可以了，但是有遇到小伙伴，还是按照老的思维方式，在生成的UI组件元素上做文章。

　　3. 专注HTML控件本身，而不是组件

　　举个例子，日期选择器，当日期修改了，我们要干嘛干嘛，直接：

$("input").change(function() {});

<br/>

　　想要修改日期范围，直接：

$("input").attr({
  "min": "2015-12-27",
  "max": "2016-12-27"
});