基于原生HTML的UI组件开发

Dear 丶 2022-06-13 08:22 600阅读 0赞

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

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

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

**例如：**

*  title提示  
    [![title提示][title]][title]
 *  选择日期  
    [![选择日期][20151221151623905.png]][20151221151623905.png]
 *  点击提交的表单验证  
    [![表单验证][20151222142540703.png]][20151222142540703.png]

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

**例如：**

*  男女款式、城市以及运费险对价格的影响  
    [![交互与最终价格][20151222142805210.png]][20151222142805210.png]
 *  表单提交事件  
    [![表单提交][20151221154020659.png]][20151221154020659.png]

下面，见证奇迹的时刻到了，点击demo页面（下图所示）的按钮进行某项目UI组件资源的加载和初始化：

[![点击测试按钮示意][2015122214303373.png]][2015122214303373.png]

结果，一瞬间，上面原始粗糙的界面一下子变成了这样子：  
[![加载CSS资源后的模样][CSS]][CSS]

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

**例如：**

*  title提示  
    [![引入UI组件后的提示][UI]][UI]
 *  选择日期  
    [![日期选择示意][20151221162536141.png]][20151221162536141.png]
 *  点击提交的表单验证  
    [![表单验证][20151221162606553.png]][20151221162606553.png]

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

请看下面的gif截图演示：  
[![业务功能不受影响示意][20151221161027795.gif]][20151221161027795.gif]

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

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

解决2个疑问：

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

**1. 为何可以基于原生HTML进行UI组件开发？**  
HTML中自带的很多原生的UI表现和UI组件的UI表现本质上是类似的，差别仅仅在于长相的粗糙和精致。

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

而设计师设计的tips组件是小黑风格，如下：  
[![引入UI组件后的提示][UI]][UI]

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

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

下图则是team决定采用的UI形式：  
[![表单验证][20151221162606553.png]][20151221162606553.png]

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

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

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

**2. 如何基于原生HTML进行UI组件开发？**  
有2个要点：① API参数直接取自HTML； ② 回调直接trigger原生事件；

我们拿上面提过的日期时间选择器举例说明下。  
[![日期选择示意][20151221162536141.png]][20151221162536141.png]

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

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

API参数，事件的回调全部源自JS参数。

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

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

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组件元素上做文章。 ![1.gif][]

**3. 专注HTML控件本身，而不是组件**  
举个例子，日期选择器，当日期修改了，我们要干嘛干嘛，直接：

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

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

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

UI组件会自动同步。没有任何组件相关的JS代码，也没有什么故弄玄虚，没有所谓的高屋建瓴，全是很简单基础的HTML操作。是不是这样的开发反而很省心，连小白用户也能上手？

于是乎，在多团队联合协作开发的时候，前端开发的进度并不会受UI组件开发影响，面向HTML，专心自身业务开发就可以了。

于是乎，实现了一个听上去很了不得的东西：**前端分离**。

不仅如此，厂子里有很多开发，负责内部项目，会写JS擅长业务功能实现，但是，UI这块是个软肋。OK，此时，我们这里面向HTML开发的UI组件体系就是其救星，对吧，直接引入CSS和JS，简单全局初始化一下（可能还有一些简单的微调），结果，页面立马高大上了，是不是很有用！

**4. 可以一次性全局处理**  
传统实现，每个具体业务的脚本里面要参与UI组件的具体API参数设置。而面向HTML的实现，API落地与具体的业务页面，于是乎，只要在项目的common.js中全局初始化一下，如下拉`Select.init()`, 具体的业务JS文件（绝大多数情况下）中就无需再出现UI组件相关的JS代码。

UI层的JS代码和业务层JS代码分离，实现进一步的「前端分离」，去耦合。对于日后的维护、升级等必定大有裨益。

### 四、总结 ###

本文主讲设计思想，至于具体的技术细节，以后有机会会慢慢分享。越是简单的成品越是需要足够的积累。

然而，现在的我再重新评估UI组件的实现，还是有一些遗憾的，主要遗憾在于，HTML层→数据层→展现层这三层概念实现的时候并没有理得很清楚。目前，HTML层和展现层没有任何问题，但是，数据层，并没有完整贯穿整个UI组件体系，导致，本UI组件体系不能很好地吸引对JSON数据有着偏执爱好的开发，以及应付潜在的极端需求。

不过，不要担心，明年，也就是16年，我会对组件设计进一步增强，首先，不考虑IE7浏览器，于是可以做的事情就更多了；其次，清晰的数据层作为中间层的代码重构等。

以上，希望本文的内容能够对大家有一点启示。

[HTML UI_demo]: http://www.zhangxinxu.com/study/201511/form-use-mpqq.html
[title]: /images/20220613/2517a56c9c244a20ad3c6a6dc228478a.png
[20151221151623905.png]: /images/20220613/40352563f3e748d6abe85f79cfa8ff81.png
[20151222142540703.png]: /images/20220613/9e7779e953424fbf9ba066ebf36f1ff3.png
[20151222142805210.png]: /images/20220613/4fd5ff578b1e4eeda68f3c580da490d3.png
[20151221154020659.png]: /images/20220613/875579a01f3843f3942951770c235bb2.png
[2015122214303373.png]: /images/20220613/5495da17467040daa103d7ad8966c9ba.png
[CSS]: /images/20220613/0364a02a6da14540a0318129bbe4b787.png
[UI]: /images/20220613/f390d5dfd23c4499b77e8b9b89d9220e.png
[20151221162536141.png]: /images/20220613/011efaba533242899f0e8a68d1b387be.png
[20151221162606553.png]: /images/20220613/7c0c472da23b4cad9dc9450d7ededf9d.png
[20151221161027795.gif]: /images/20220613/2a4cdc31d9b648e3bbe0c3365c1b4de3.png
[20151222143435693.png]: /images/20220613/6e2733e771894f629cb10d26a6009e44.png
[1.gif]: /images/20220613/baff3ec0acab44a6ba481aba41732913.png