欢迎来到做网站吧,请先 登录注册

教程观看记录

资源投稿 | 网站地图 | 联系我们 | 收藏本站 |

做网站吧 > HTML5 > HTML5+CSS3 >
收 藏
2600

基于原生HTML的UI组件开发

所属栏目:HTML5+CSS3 来源:未知 内容发布:做网站吧

  一、基于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原生事件;

 

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

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

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组件元素上做文章。

  

 

  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数据有着偏执爱好的开发,以及应付潜在的极端需求。

文章关键词:原生HTML  UI组件  组件开发  

相关推荐
网友评论
评论列表(网友评论仅供网友表达个人看法,并不表明本站同意其观点或证实其描述)
上一篇:HTML5视频播放器<video>和音频播放器<audio>用法
下一篇:CSS3制作绚丽圆形动态按钮

返回顶部