关于单页应用(SPA)的经验之谈

  1. 云栖社区>
  2. 博客>
  3. 正文

关于单页应用(SPA)的经验之谈

吕亚辉 2017-07-14 21:27:00 浏览1084
展开阅读全文
时下SPA单页应用如火如荼,对前端乃至后端开发都带来不小的冲击和变革。笔者整理了下笔记,决定写一下以前基于iframe做单页博客的一些经验方法。
对于单页应用,笔者没有找到最官方的定义。在笔者看来,在用户操作过程中,浏览器始终不会重载整个页面的web应用,便可以称为单页应用。这里不包括https://im.qq.com/这种宣传单页
例如coding.net、网易云音乐播放、QQ空间、移动端大量的react案例(比如手Q健康、公众号)等等

单页站点优劣

单页站点的优势主要有三点     

传输数据少

单页站点的重点是局部刷新,因此每次更新,传输的数据少,减少后端压力,甚至对于完全前后端分离的SPA应用,只需要传输少量json数据即可。这一点在移动端显得尤为重要,许多应用前端代码并不会频繁更新,完全可以由前端直接缓存起来,每次使用只需与后端交互少量数据,这样既省流量也能让用户获得接近native的体验

服务可不中断

一些特殊网站,如音乐播放、IM聊天等,不希望因为页面全部重载造成服务中断。单页应用因为局部刷新,可以将这些服务放置在刷新范围之外,持续提供服务

前后端开发更规范

前端也可按照MVC的模式更好的模块化开发,而后端开发仅仅只需要开发数据操作接口,对前后端开发而言都是一种解放
 
但单页站点也带来了一些新的问题,比如

首次加载数据大耗时长

特别是目前基于angular或者react的纯前后端分离的SPA,结合一些javascript方言,编译出来js相当的大,笔者曾在内网亲眼目睹10M级别的js文件,即便以内网的网速首次打开也需要3秒左右。为每个模块单独编译js是种办法,但实际操作会可能发现,随着项目越做越大,拆分成独立模块编译的成本会越来越大,最终不得不委曲求全整站使用一个js,除非从一开始就有良好的规范限制。

极差的SEO(搜索引擎优化)

众所周知,通过请求url即可获取到大量页面正文文本的页面是对搜索引擎最为友好的,虽然现在的爬虫已经具备解析运行页面js脚本索引动态内容的能力,但是每个网站千奇百怪,爬虫需要考虑触发什么事件、按什么顺序触发才能获取更多内容,索引动态内容的难度要远远大于索引静态内容。而目前主流的单页应用,几乎都是以前端js模板引擎来渲染html页面数据,直接通过url获取到的内容极少,这对搜索引擎非常不友好。SEO最差的单页应用可能仅仅只有首页能够被搜索引擎收录。这成了制约单页应用发展的一大障碍,即便现在又方案可以提高收录,但效果还是不好

导航需要人为处理

浏览器对div以及早期浏览器对iframe都不记录历史记录,因此需要开发对浏览器的前进后退做实现,通过修改hash或者history API来实现前进后退(后面会提到)

单页应用的实现方式

笔者了解到的,目前主要两种实现方式

iframe

其一,使用iframe的优点之一就是开发简单,目前的浏览器都已经对iframe url发生修改产生历史记录。
其二,除了响应式问题的兼容性不好之外(也正因此iframe很不适合用在移动端),iframe作为使用多年的浏览器技术之一,在许多方面的兼容性要好许多,也是一些新技术在低版本浏览器上不可用时的替代解决方案,如contentEditable。
其三,iframe与父文档相对独立,可以不受父文档的影响,想必这也是目前一些网站(网易云音乐,QQ空间,各大邮箱)继续使用iframe的主要原因。

ajax+div+historyapi

这种方式实现要更复杂,开发要自己实现url管理,以达到前进、后退跳转等能力,不过目前都已经有成熟的路由库可以使用,另外基于div模式的SPA,开发需要考虑全局对局部的影响,包括css、事件等。这种方式的优点是刷新要更轻量,js库和css样式在首次加载即可,局部页面可以只加载少量的数据,并且基于div响应式效果在移动端要更好。因此这也成了目前流行的前端框架angular、react等选用的方案。

基于iframe制作单页博客

笔者的博客制作于2015年,当时的PC浏览器应该不支持iframe历史记录,所以笔者选择通过修改hash的方式实现历史记录(浏览器对hash的修改会记录历史记录),选择基于iframe制作基于两个原因:一、希望浏览博客时不论怎么跳转,可以不中断播放音乐;二、iframe相对全站ajax+div而言要更简单易行。博客地址http://movesun.com,博客布局参考 http://www.kotonohanoniwa.jp/
做法是绑定所有需要在iframe中打开的a标签的click事件,当点击a标签时,将a标签url中的path路径修改为浏览器url的hash值。例如我想访问的是 http://movesun.com/blog/list,则将/blog/list作为hash值设置到地址栏 ,因此在浏览器地址栏看到的地址就变为了http://movesun.com/#/blog/list
 
因此在父文档中有这样一段js
 1 $('a[target="contentFrame"]').click(function(){
 2     var $this = $(this),
 3         url = $this.attr('href'),
 4         mainHost = location.host,
 5         i = url.indexOf(mainHost);
 6     $active.removeClass('active');
 7     $active = $this.parent('li');
 8     $active.addClass('active');
 9     if(i !== -1){
10         url = url.substr(i + mainHost.length);
11     }
12     window.location.hash = '#' + url;
13     return false;
14 });

在iframe页面(子页面)中,也有一段类似的js,为iframe中的页面超链接绑定事件

 1 $('a').click(function(){
 2     var url = $(this).attr('href')
 3     if(url && url != '#' && url.indexOf('http') == 0){
 4         var mainHost = window.parent.location.host,
 5                 i = url.indexOf(mainHost);
 6         if(i !== -1){
 7             url = url.substr(i + mainHost.length);
 8         }
 9         window.parent.location.hash = '#' + url;
10     }
11     return false;
12 });

注意这两段代码,修改的都是父文档(顶层窗口)地址栏的hash值。所以,只需要在父文档中监听onhashchange事件,在事件响应中设置iframe的src 进而load子页面。

1 $container = $('div.page-body > iframe');
2 window.onhashchange = function(){
3     $container.attr('src',location.hash.substring(1));
4 };

 iframe高度不能根据内容自适应,需要在子页面load之后刷新iframe的高度

 1 var refreshHeight = function(){
 2     var $this = $container,
 3         minHeight = $('.page-right').height() - $('.top-menu').height() - 20,
 4         contentHeight = $this.contents().find('body').height() + 10;
 5     $this.height(contentHeight < minHeight ? minHeight : contentHeight);
 6 };
 7  
 8 $container.load(function(){
 9     refreshHeight();
10 });
11 // 首次刷新,否则加载过程中会看到白框
12 refreshHeight();

到这里基本已经实现任意跳转、回退、前进页面不再刷新整个页面。下面的代码是为了解决当打开多个顶层文档时(开多个窗口),音乐不重复播放,方法也很简单,在localStorage中记录顶层文档的数量,每开一个新窗口加1,关闭时减1,只要记录数大于1便不自动播放。 

 1 if(window.localStorage){
 2     var $window = $(window);
 3     $window.on('beforeunload',function(){
 4         console.log('-1');
 5         localStorage.framePage = localStorage.framePage - 1;
 6     });
 7  
 8     window.addEventListener("storage", function(e){
 9         console.log("oldValue: "+ e.oldValue + " newValue:" + e.newValue)
10     });
11 }
12 var autoplay =  location.host !== 'movesun.qq.com';
13 if(window.localStorage){
14     if(Number(localStorage.framePage) >= 1){
15         autoplay = false;
16     }
17  
18     if(isNaN(localStorage.framePage) || Number(localStorage.framePage) <= 0) localStorage.framePage = 1;
19     else {
20         localStorage.framePage = Number(localStorage.framePage) + 1;
21     }
22 }

博客依然有两个问题需要解决

1、目前的浏览器已经支持记录iframe变更的历史记录,通过hash记录历史就显的没有必要了。目前网站每次跳转实际产生了两条历史记录。后面找时间移出hash记录或者禁用iframe历史记录

 

2、考虑到搜索引擎收录的超链接应该是非hash模式的url,比如用户看到的是movesun.com/#/blog/list ,而实际收录的却是movesun.com/blog/list,通过site:movesun.com指令搜索也可以看到

直接访问这类url地址,将直接打开iframe里的内容,所以,当用户直接点击搜索引擎的结果进入博客时,应该将用户跳转到hash模式,页面才能正常显示,但这样对搜索引擎而言,会陷入一个无限循环,影响搜索引擎收录。

前端因直接面向用户,使得技术也更新迭代的频繁,前端开发人员也需要不断学习以追赶时代的潮流。而反观后台技术,十年来都没什么及其巨大的变化,很多技术经久不衰,后端开发完全有一招鲜吃遍天的架势。这也是的前端人员比较抢手,在一些公司都存在前端与后台人力严重不平衡的现像,十几位后台搭配一位前端的事情,也不是没有,奇货可居,优秀的前端是非常吃香的。

网友评论

登录后评论
0/500
评论
吕亚辉
+ 关注