最近用vue+vue-router做了个单页应用的项目,页面大概有15个左右。积累了一些开发经验在此做一些记录.本文主要从可维护性方面来考虑SPA的开发实践
全站的颜色定义放在一个less或者scss的文件里,其他组件和页面import这个配置来引用颜色。
示例代码:define.scss
$bgColor: #fff;
$color:#619eee;
$fontColor:#333333;
$fontColor01:#A5A5A5;
$fontColor02:#4a4a4a;
$fontColor03:#448CFF;
$color300:#ed5630;
$color3001:#fbfbfb;
$accpetColor:#2fbe27;
$refusedColor: #de0101;
$hrefColor:#4a90e2;
$redColor:#ff4c4c;
好处:
方便维护整站的色彩风格,后续遇到VI升级改版等,你就偷着乐吧。
vue,vue-router单独抽出来,用script标签引入
bad case
npm install vue
npm install vue-router
//js
import Vue from ‘vue‘
import VueRouter from ‘vue-router‘
good case
<script src="/path/to/vue.js"></script>
<script src="/path/to/vue-router.js"></script>
或者
<script src="https://g.alicdn.com/cn-yz/bmw/0.2.5/vendor/vue??2.2.0.js,vue-router.min.js“></script>
好处:
import过来的js会和你的业务代码打包在一起。无谓的增加代码的体积,而且vue这类基础包的更新频率是低于业务代码的。单拆出来加载有利于浏览器缓存
拆出来的会比import在一起的体积减小30k左右
把你的异步请求方法封装在一个基础组件里
ex:
//myTool.js
function get(param){
$.get(param);
}
function post(param){
$.post(param)
}
你可能会质疑。。这样有什么用
1.当你的应用跑在在多个容器的场景,比如手淘,他有个mtop的请求模式(一种接口调用方式),比如还需要跑在钉钉里面。你只需要在里判断一下容器环境就可以区分对应的api调用方式
ex:
function get(param) {
switch (container) {
case "taobao":
mtop.request(param);
break;
case "web":
$.get(param)
break;
case "weixin":
//balabala
break;
default:
break;
}
}
2.当你遇到csrf攻击需要给每个请求添加token。如果你不知道什么是csrf,请点击这里
3.你可以在这里给每个请求添加一个loading模态框,免去每个方法调用前自己添加的烦恼
ex:
function get(param){
var show = param.showloading===undefined?true:param.showloading;
if(show){
$.showPreloader();
}
$.get(param);
}
4.v-model与v-on:input的坑
ex:vue 2.2.0+
<input type="text" v-model="a" v-on:input="myInput"/>
<script>
function myInput(){
this.a = "abc";
}
</script>
当你在myInput方法里做一些操作,比如校验输入值,你会发现数据并没有更新到对应的input,这是因为v-model也监听了输入框的input事件
解决办法:绑定value值,js更新value
<input type="text" :value="a" v-on:input="myInput"/>
<script>
function myInput(){
var formattedValue = "abc";
this.a = formattedValue;
this.$refs.input.value = formattedValue
this.$emit(‘input‘, Number(formattedValue))
}
</script>
对于中文:v-model也不是很适用
对于要求 IME (如中文、 日语、 韩语等) (IME意为’输入法’)的语言,你会发现v-model不会在 ime 输入中得到更新。如果你也想实现更新,请使用 input事件。
详见链接使用自定义事件的表单输入组件
5. 优雅解决ios的fixed问题
ios的fixed问题由来已久,在单页应用中我们免不了需要处理这样的bug。如何优雅解决这个问题
如图:这是一个经典的移动端布局。header和footer相对于浏览器固定,body高度可变。
这样的布局单独一个页面没什么难度。不过当你把footer设为fixed的时候会在ios上看到奇异的效果。
当单页应用里有很多个这样的页面,而且header的高度也不是固定的时候,你就会发现每个页面都需要搞定body的高度css还是有点繁琐的。。
有没有一个优雅的方式来做这个事情。让代码可维护性更好。
这个布局的难点在于如何搞定body在不同机型上的高度。如果用纯css来做,可能需要用到calc,或者boder等之类的,而且针对每个页面不header不同,需要重新计算body的高度。
虽然我们在布局方面不推荐使用js来处理,不过在是个时候是使用js处理body的高度的时候了。
步骤:
我们需要获取容器的高度。
var w_height = $(window).height();
获取header和footer的等fixed元素的高度
这里我们可以给需要fixed的元素加个自定义属性
fixed-box="true"
<div class="header" fixed-box="true"></div>
<div class="body " fixed-box="scroll">
//balabalaba
</div>
<div class="footer" fixed-box="true"></div>
在每个页面被路由到加载的时候mounted触发一个事件,告知js需要计算处理body高度
mounted: function() {
_body.trigger("mounted");
},
在main.js等入口函数里监听这个事件处理相关逻辑
jWin.on("mounted", function () {
//元素加载后计算可滚动元素的区域宽度
var height = 0;
$("[fixed-box=‘true‘]").each(function () {
height = height + $(this).height();
});
var h = w_height - height;
$(‘[fixed-box="scroll"]‘).height(h);
});
这样整个页面的布局都可以在这个js里处理,后续新增页面只需要做两个事情:
1.给页面加fixed属性。
2.在mounted方法里触发事件。
6.如何拉起其他app
webapp拉起其他native app是常见的场景,通常我们都通过scheme来拉起其他app
不过在ios中偶尔会遇到这个拉起的动作偶尔会被一些web容器记录在history里。为了处理这个情况通常在ios里面我们都是建立一个iframe的元素然后把iframe的src指向这个schema,然后把iframe插入dom,在延时删除这个元素。这样history里就不会有这个记录了。不过此方法对安卓无效。