1 简介
今次给大家安利的这两种工具,flex当为页面显示布局中很强大的一个属性,属于css范畴.
而vue则属于一种js插件,其作用在于将页面显示与js数据近乎完美的完全区分开,而又使两者遥相控制(当然主要是js数据控制页面显示).
2 flex
1.背景
谈到页面布局,我想很多人都曾经遇到过一个难题,即:==如何使元素垂直居中?==(其中最典型的一个例子如yct的登录页面)
方案当然有很多,但就我自己使用的经验而言,并没有一种十分完美的方案.所谓完美,至少需要考虑以下几种要素:
- a.必须是动态居中,即不确定外围像素数量为多少的情况下即可居中;
- b.尽量不要使用js实现(一在于js主要负责逻辑,我们倾向于将逻辑与显示尽量区分开,二在于js实现必然调用到了事件,这样就需要考虑导致外围高度变动的事件种类及浏览器的兼容性问题);
- c.必须兼容尽量多的外围元素和子元素种类,不论是p标签还是div;
- d.在以上基础上,尽量减少增加包裹元素的数量,当然这点相比以上几点而言就不是那么重要了.<br> (此处可以大家讨论下各自有什么比较好的方案)
2.一个比较完美的解决方案
这里先放上对flex属性介绍的比较丰富的链接:
语法:http://www.ruanyifeng.com/blog/2015/07/flex-grammar.html
示例:http://www.ruanyifeng.com/blog/2015/07/flex-examples.html
对于flex而言,解决方式就很简单了,对于大多数类型的dom,两步即可解决:
- a.外围元素设置display:flex;
- b.外围元素设置align-items:center; 特别需要说明,flex在09年就已经提出了,得到所有主流浏览器的支持,故其兼容性是不必担心的.<br> (此处根据时间之多寡,简要描述flex的其他功能)
3 vue
1.背景
从开始写页面开始,我们有很大一部分精力都放在了以处理dom为主的页面显示与数据之间的协调(后文统一称为==数据显示交互==),
这里我们不妨先把曾经用过的方法逐一列举出来,然后列举其优缺点.
2.FreeMarker
应该是公司大多数人都最熟悉的一种方法(FreeMaker前台与后台都有涉及,但这里我们只讲前台),但缺点实在很多:
- a.仅支持静态的数据显示交互.这是一个绝对的硬伤,使得动态性不强的页面还可通过刷新来实现伪动态(刷新这种方案对不论速度还是用户体验而言都不是很好),动态性稍强一些的页面就干脆不能使用这种方式实现了.
- b.语法与html语法的相似性.客观而言,这并不是所有情况这都是一个缺点,放在具体的案例中,有些地方是可以接受的,如include.但关键是在一个页面中,只要有一个因为这个特性造成的缺点,就会对整个页面的人工解析与理解造成困难;
- c.没有可用的语法检测插件/方法支持.这个只要看下我们项目内html文件内遍是红叉即可有所了解.红叉尚且如此之多,就更不必说语法提示了.事实上,这个插件即使有也应该是非常难做,因为它既需要考虑html,有需要考虑css,还需要考虑js,所有的地方它都可进行干涉.这个功能诚然强大,但正因为过于强大,便难以限制,更何况根本没有可供进行限制语法的插件.所以我们最常见到前台原因造成的错误,多数都是FreeMarker造成的.
- d.数据难以复用,更难以缓存.这里说的缓存特指前台缓存.虽然截止到目前为止,我们的系统都还没有考虑任何缓存问题,但对于一些数据量较大但变化不大的数据(大多数select使用数据),是可以考虑通过数据缓存减少服务器和数据库(数据库可以减少left join,此处可能有人不太明白,可以细讲)压力和提升前台数据传输速度的.一般而言,ajax传输的数据是比较容易转换为缓存数据的.关于缓存的细节,这里不再说,也许以后有一天我们的系统会考虑这个事情.
- e.所有数据在html中均为显式,安全性较差.不止是密码,还有其他企业想要保密的数据.不过安全性这点和上一点改善系统性能一样,我们现在没有改善的动力.
优点还是有的: - a.它凌驾于所有前台内容的优先级及万事皆允的干涉力.但怎么说呢,FreeMarker好比是战争中的核武器,威力确实强大,但没有更强大可以限制它的手段,所以副作用也是十分明显,稍微不注意便是500遍地;
- b.唯一可以从request和session中直接获取数据的手段.之后所讲的几种方案全部都是通过ajax间接获取.这基本上就是我使用FreeMarker两个地方之一的原因--提供==差异种子==.
现在谈谈我使用FreeMarker的两个地方,其实在我的自定义规范中也有涉及: - a.<#include "../../something.html">:这里引入的html只有css和js插件的引用,及少数几个用惯了的静态配置;
- b.绝对不超过三个的差异种子,即在页面的数据配置中的内容,且需经过严格的格式保证,以形成差异种子(差异种子:同样模板页面用以区分不同内容,形成差异的种子).
以上使用的地方,均从较大范围降低FreeMarker出现错误的可能.
(此处可以讨论下如果完全不使用FreeMarker在页面上的语法,如何实现差异种子)
3.jquery操作dom
由于FreeMarker仅支持静态的数据显示交互,对于动态性较强的页面,如yct的销售开单主页面/收付款主页面,首先考虑到的方法,即是使用jquery来操作dom.
应该说,操作dom不使用jquery也可以做到,但jquery无疑会极大降低操作dom的难度.
既然是数据显示交互,就必然涉及到两个方面,其一是数据到显示,其二是显示到数据(譬如收集input的数据).前者没什么好说的,后者则就我所知,共有3种流派:
- a.不论是input还是html,均原样保存于页面,取值时用$(dom).val()或$(dom).html()等方式获取.此种方法,是我在最开始的时候使用的一种方案,优点即是,数据只有一套,处理起来方便且可靠,不易出错,缺点在于,如果要对页面显示进行较大范围的修改,尤其是短时间内进行的统一修改,会很不方便;
- b.所有数据,除非是从input中获取的数据,一律均在js数据中留有一个备份.此种方法,应是建兴之前常用的一种方法,与第一种流派相对,优点即是在修改页面显示时不必顾虑对数据取值的影响,缺点在于数据基本总是要有两套,逻辑复杂程度无疑会增加,错误几率也会上升,可能会导致数据与显示不一致的问题;
- c.仍是所有数据保存于页面,但对核心数据和经常操作的数据且没有Input的显示,额外提供hidden input来set,这样数据再取回的时候只需从hidden input中获取即可.此种方法,是我在使用第一种流派吃了些短时间大范围修改页面的亏之后想出的一种折中方法.它所持有的数据要略多于一套,但远小于两套,且由于都是在html内进行的操作,不易出错.而在进行短时间大范围修改页面时,由于是hidden input,也不必卷入风波.唯一的缺点就是,核心数据量越多,hidden input也会逐渐增多,复杂程度会愈加复杂,但相比于前两者,这第三个流派应该算是较成熟的一种方案了.
以上三种流派,相信在座的写过前台html的,每个人都曾经使用过其中的一种,或者是两三种中的一个中间方案.
不论是哪种方案,似乎都不是那么完美,总觉着代码应该可以更精简,逻辑可以更简单.
4.插件
插件按作者分有现成插件和自定义插件(yys-util),按用途分,又主要分为jquery,显示改变(如bootstrap-switch,select2)和功能集成(如datatable,jquery-form),对于很多插件而言,两种用途并没有太清晰的界限,如ztree既有显示改变,又有功能集成的用途.
谈数据显示交互,自然以功能集成这个用途为主.插件使用优点多多,我们在此姑且不提,只谈谈实际使用过程中的缺点.
- a.多数人使用的现成插件,在功能扩展上不甚容易.这是最主要的问题,且情况种类很多.由于使用现成插件,过程中必然有所限制范围,想要用一些api之外的功能就很困难,改源代码还需从头阅读理解,十分不易(如h-ui实现不同url打开同一tab).而不改源代码,通过后置方案处理,仅适用于少数几种情况,且即使可以实现,往往也会存在一个时间差,用户体验较差(如select2显示库存余量并以不同颜色标示);
- b.有些改变显示插件在动态处理方面,是比较麻烦的(此处的动态处理,主要指jquery操作dom方式).如bootstrap-switch动态体现在table的每一行,开始用的人可能会很纳闷为什么就自动回到普通checkbox的形式了.
- c.不同的插件之间可能存在兼容性问题.如在非iframe形式layer中调用select2.
- d.现成插件数量稀少,不可能解决所有问题,而使用自定义插件解决时,又往往会遇到方便性与全面性难以兼容的平衡难题.我自己写的自定义插件数量也不算少了,包括很多兼具显示改变用途的插件.为了实现一个功能的继承,有时候想写一个大而全的插件,但是既浪费时间与脑力,又要担心过于复杂的形式可能会带来对其他人而言较高的学习成本.
总的来说,插件无论在何时都是有其不可替代的作用的,但仅能解决很有限的一些问题.
5.我是如何遇到了vue
使用vue倒并非一个偶然的事件.
事实上,在发现jquery操作dom的诸多不完美之处时,我就在构思一个更完美的方案,解决数据显示交互的简洁性问题.
期间甚至考虑过自己写一个类似的插件,奈何js功底较差,始终没有思路.
直到有一天,我在学习微信小程序的时候,发现这个写法就是我想要的那种完美的数据显示交互方案!
后来辗转知道了regular和其他类似框架,包括react,angular,vue.
最后综合评估下我选择了vue.原因总结下来大致如下:
- a.vue的学习成本较平滑;
- b.vue使用范围较广泛,国际化插件,仍在不断更新;
- c.vue的语法与微信小程序的语法十分接近.
6 vue简介
传送门:https://cn.vuejs.org/v2/guide/index.html
(此处大概介绍几个自己写的vue页面)
7 兼容性评估
此处的兼容性分两方面来讲:
其一是浏览器的兼容性.vue兼容js E5以上标准,如ie8,所有主流浏览器都是支持的; 其二是与以往数据显示交互写法的兼容性.
- a.与FreeMarker之间的兼容性.前面也说到了,FreeMarker无处不可干涉,所以能否兼容,不在于vue,而在于FreeMarker的内容本身.当然不论从哪种角度讲,FreeMarker我都是建议仅用于建议用的那两个地方.
- b.与jquery操作dom的兼容性.这个我自己没有试过,网上说有不兼容的情况.我自己的想法是,jquery操作dom能做的事,vue都能做.对于老页面,自然没有办法再改回来,除非重构,故老页面不建议再和vue掺和了.但对于新页面,我建议就不要使用jquery操作dom,而统一改为vue.
- c.与插件的兼容性.这个倒不能一概而论了.我自己目前使用的经验是,还没有遇到不能兼容的现成插件,有些插件使用vue的模式模板后,比以前更方便了.
综合来讲,在写新页面的时候,兼容性不是问题.
