浅谈SPA

2018-09-18 06:38:18来源：博客园阅读 ()

　　最近一直在学习关于Vue的一些知识，由于遇到了问题，去网上查找资料，收获颇丰，在此分享。

1. 什么是SPA？

　　单页Web应用（single page web application, SPA）,就是只有一张Web页面的应用，是加载单个HTML页面并在用户与应用程序交互时动态更新该页面的Web应用程序，是指在浏览器中运行的应用，在使用期间不会重新加载页面。像所有的应用一样，它旨在帮助用户完成任务，比如“编写文档”或者“管理Web服务器”。可以认为单页应用是一种从Web服务器加载的富客户端。

　　速度：更好的用户体验，让用户在web app感受native app的速度和流畅，
　　MVC：经典MVC开发模式，前后端各负其责，后端只需要提供数据接口
　　ajax：重前端，业务逻辑全部在本地操作，数据都需要通过AJAX同步、提交。
　　路由：在URL中采用#号来作为当前视图的地址,改变#号后的参数，页面并不会重载，这个也就是哈希。

　　SPA也是当今网站开发技术的一种趋势和潮流，毕竟前端三大框架不是盖的~~，很多的传统网站都在或者已经转型为单页Web应用，新的单页Web应用网站（包括移动端平台上面的）也雨后春笋涌现出来。

　　单页Web应用和前端工程师们息息相关，因为主要的变革发生在浏览器端，用到的技术其实还是HTML+CSS+JavaScript，所有的浏览器都原生支持，当然有的浏览器因为具备一些高级特性，从而使得单页Web应用的用户体验更上一层楼。关于单页应用的优点和缺点，下一个问题就说。单页Web应用，顾名思义，就是只有一张Web页面的应用。浏览器一开始会加载必需的HTML、CSS和JavaScript，之后所有的操作都在这张页面上完成，这一切都由JavaScript来控制。因此，单页Web应用会包含大量的JavaScript代码，复杂度可想而知，模块化开发和设计的重要性不言而喻。

单页Web应用程序的优点：

　　1.首先，最大的好处是用户体验，对于内容不改动的不需要加载整个页面。这样做好处颇多，因为数据层是和UI的分离，可以重新编写一个原生的移动设备应用程序而不用（对原有数据服务部分）大动干戈。

　　2.单页面Web应用层程序最根本的优点是高效。它对服务器压力很小，消耗更少的带宽，能够与面向服务的架构更好地结合。

单页Web应用程序的缺点：

　　虽然还有一些历史遗留问题（大部分是针对HTML5的改进）以及SEO。如果你看中SEO，那你应该使用网站而不是Web应用。目前该技术还存在一些争议，但这并不是重点，因为这种类型的体系架构为SAAS Web Apps提供了一个极大的可用性。

程序结构 -- 重点

　　单页Web应用程序的结构很简单：首先传递HTML文档框架；然后使用JavaScript修改页面；紧接着再从服务器传递更多数据然后再修改页面，如此循环。从性能的角度看，在现代浏览器中单页面Web App已经能够和普通应用程序相媲美，而且几乎所有的操作系统都支持现代的浏览器。使用HTML+CSS+JavaScript编写应用程序，能使更多的人们都加入到程序开发的行列。

　　这足以说明，在Web设计过程中标志着Web将呈现一种新的趋势，它将一个分离的功能层作为API并将表示层用APP的形式体现出来（HTML5或Native）

单页面+API模式比基于应用程序的HTML多重页面更加灵活，因为底层API可用于多种不同的上下文、形式因素和设备类型。一旦网页内置了API，能够满足客户不同需求（比如合作伙伴vs最终用户）。
该模式意味着本地Web应用能够为用户无论是基于什么平台提供更接近一个本地移动或桌面应用程序的体验。
协议（如openAuth（oAuth））成为作为用户授权的黄金标准已被广泛采用，提供了一个共同的模式。从应用程序好饿内容中将单独登录/授权问题分离出来。也就是说用户的身份可以从内容、功能和用户体验中清晰的分离出。

　　一个单页面Web应用程序就是一个Web应用程序，但结构哦不同。其中最重要的是：在第一次请求的时候，所有的标记语言（HTML）就已经传输到客户端，其余的请求都通过REST API获取JSON数据，数据的传输通过Web Socket API或远程过程调用。单页面应用程序可以说是分拆Web技术的最后一步----通过分离（css）内容，改进架构（XML和XSLT）上的灵活性，调用服务器（AJAX）再到解压应用程序的导航页面结构，因此，这在Web发展中是个历史性的转折点。

　　目前这只是单页面Web应用开发的初期，但可以看出将单页面应用、APIs以及JavaScript结合在一起将成为许多流行应用的规范。

　　所以，当被问到“HTML5是App+API？”，我们会说，“两者皆是---”将两者结合在一起要比以往快得多。“单页面应用是一块非常大的拼图。当然，导航、历史性和SEO等问题也成为单页面Web应用的诟病”

单页面应用的演进

　　在这里介绍一些Hash的内容先，单页面应用是如何实现不刷新网页而进行跳转的呢？

HTML中的hash（#号）

1.#的含义

　　#代表网页中的一个位置。右面的自负就是代表的位置信息：如

　　http://localhost：8080/cbuild/index.html#one

　　就代表网页index.html的one位置。浏览器读取这个URL后，会自动将one位置滚动至可视区域。

　　　　为网页制定标识符：

　　　　一是使用锚点比如 <a name="print"></a>

　　　　二是使用id属性，比如<div id="print"></div>

2.HTTP请求不包括#

　　比如： http://localhost：8081/cbuild/index.html#first

　　浏览器实际发出的请求是这样的

　　GET/index.html

　　而不包含 #first

3.#后的字符

　　在第一个#后面出现的任何字符，都会被浏览器解读为位置标识符。这意味着，这些字符都不会被发送到服务器端。

　　比如，下面URL的原意是指定一个颜色值：

　 http://www.example.com/?color=#fff

　　但是，浏览器实际发出的请求是：

　　GET/?color=

　　Host: www.example.com

　　可以看到，“#fff”被省略了，只有将#转码为$23，浏览器才会将其作为实义字符处理。也就是说，上面的网址应该被写成：

　　http://www.example.com/?color=%23fff

四、改变#不触发网页重载

　　单单改变#后的部分，浏览器只会滚动到相应位置，不会重新加载网页。

　　比如，从

　　http://www.example.com/index.html#location1

　　改变到

　　http://www.example.com/index.html#location2

　　浏览器不会重新向服务器请求index.html

五、改变#会改变浏览器的访问历史

　　每一次改变#后的部分，都会在浏览器的访问历史中增加一个记录，使用"后退"按钮，就可以回到上一个位置。

　　这对于ajax应用程序特别有用，可以用不同的#值，表示不同的访问状态，然后向用户给出可以访问某个状态的链接。

　　值得注意的是，上述规则对IE6和IE7不成立，它们不会因为#的改变而增加历史记录

六、window.location.hash读取#值

　　window.location.hash这个属性可读可写。读取时，可以用来判断网页状态是否改变；写入时，则会在不重载网页的前提下，创造一条访问历史记录。

七、onhashchange事件

　　这是一个HTML5新增的事件，当#值发生变化时，就会触发这个事件。IE8+、Firefox 3.6+、Chrome 5+、Safari 4.0+支持该事件。

　　它的使用方法有三种：

1 window.onhashchange = func;
2 <body onhashchange="func();">
3 window.addEventListener("hashchange",func, false);

　　对于不支持onhashchange的浏览器，可以用setInterval监控location.hash的变化。

八、Google抓取#的机制

　　默认情况下，Google的网络蜘蛛忽视URL的#部分。

　　但是，Google还规定，如果你希望Ajax生成的内容被浏览引擎读取，那么URL中可以使用"#!"，Google会自动将其后面的内容转成查询字符串_escaped_fragment_的值。

　　比如，Google发现新版twitter的URL如下：

　　http://twitter.com/#!/username

　　就会自动抓取另一个URL：

　　http://twitter.com/?_escaped_fragment_=/username

　　通过这种机制，Google就可以索引动态的Ajax内容。

　　单页面Web应用就是根据上述的#，监控#值的改变去对应的改变页面。

路由：页面跳转与模块关系

　　要说起路由，那可是有很长的故事。当我们在浏览器上输入网址的时候，我们就已经开始了各种路由的旅途了。

浏览器会检查有没有相应的域名缓存，没有的话就会一层层的去向 DNS服务器寻向，最后返回对应的服务器的 IP 地址。
接着，我们请求的网站将会将由对应 IP 的 HTTP 服务器处理，HTTP 服务器会根据请求来交给对应的应用容器来处理。
随后，我们的应用将根据用户请求的路径，将请求交给相应的函数来处理。最后，返回相应的 HTML 和资源文化

　　当我们做后台应用的时候，我们只需要关心上述过程中的最后一步。即，将对应的路由交给对应的函数来处理。这一点，在不同的后台框架的表现形式都是相似的。

　　虽然表现形式有一些差别，但是总体来说也是差不多的。而对于前端应用来说，也是如此，将对应的 URL 的逻辑交由对应的函数来处理。

　　使用规则引擎来处理路由与函数的关系。稍有不同的是，后台的路由完全交由服务器端来控制，而前端的请求则都是在本地改变其状态，并且同时在不同的前端框架上，他们在行为上还有一些区别。这取决于我们是否需要后台渲染，即刷新当前页面时的表现形式。

数据：获取与鉴权

　　实现路由的时候，只是将对应的控制权交给控制器（或称组件）来处理。而作为一个单页面应用的控制器，当执行到相应的控制器的时候，就可以根据对应的 blog/12 来获取到用户想要的 ID 是 12。这个时候，控制器将需要在页面上设置一个 loading 的状态，然后发送一个请求到后台服务器。

　　对于数据获取来说，我们可以通过axios，我们仍然是写类似于的形式：

1 axios.get(url)
2     .then(res=>{
3         console.log(res.data)
4     })
5     .catch(err=>{
6         console.log(err);
7         throw err;
8     })

　　模型麻烦的地方在于：转变成想要的形式。后台返回的值是可变的，它有可能不返回，有可能是 null，又或者是与我们要显示的值不一样——想要展示的是 54%，而后台返回的是 0.54。与此同时，我们可能还需要对数值进行简单的计算，显示一个范围、区间，又或者是不同的两种展示。

　　同时在必要的时候，我们还需要将这些值存储在本地，或者内存里。当我们重新进入这个页面的时候，我们再去读取这些值。

　　一旦谈论到数据的时候，不可避免的我们就需要关心安全因素。对于普通的 Web 应用来说，我们可以做两件事来保证数据的安全：

采用 HTTPS：在传输的过程中保证数据是加密的。
鉴权：确保指定的用户只能可以访问指定的数据。

　　目前，流行的前端鉴权方式是 Token 的形式，可以是普通的定制 Token，也可以是 JSON Web Token。获取 Token 的形式，则是通过 Basic 认证——将用户输入的用户名和密码，经过 BASE64 加密发送给服务器。服务器解密后验证是否是正常的用户名和密码，再返回一个带有时期期限的 Token 给前端。

　　随后，当用户去获取需要权限的数据时，需要在 Header 里鉴定这个 Token 是否有限，再返回相应的数据。如果 Token 已经过期了，则返回 401 或者类似的标志，客户端就在这个时候清除 Token，并让用户重新登录。

数据展示：模板引擎

　　现在，我们已经获取到这些数据了，下一步所需要做的就是显示这些数据。与其他内容相比，显示数据就是一件简单的事，无非就是：

依据条件来显示、隐藏某些数据
在模板中对数据进行遍历显示
在模板中执行方法来获取相应的值，可以是函数，也可以是过滤器。
依据不同的数值来动态获取样式
等等

　　不同的框架会存在一些差异。并且现代的前端框架都可以支持单向或者双向的数据绑定。当相应的数据发生变化时，它就可以自动地显示在 UI 上。

　　最后，在相应需要处理的 UI 上，绑上相应的事件来处理。

　　是在数据显示的时候，又会涉及到另外一个问题，即组件化。对于一些需要重用的元素，我们会将其抽取为一个通用的组件，以便于我们可以复用它们，并且在这些组件里，也会涉及到相应的参数变化即状态改变。

交互：事件与状态管理

　　完成一步步的渲染之后，我们还需要做的事情是：交互。交互分为两部分：用户交互、组件间的交互——共享状态。

组件交互：状态管理

　　用户从 A 页面跳转到 B 页面的时候，为了解耦组件间的关系，我们不会使用组件的参数来传入值。而是将这些值存储在内存里，在适当的时候调出这些值。当我们处理用户是否登录的时候，我们需要一个 isLogined 的方法来获取用户的状态；在用户登录的时候，我们还需要一个 setLogin 的方法；用户登出的时候，我们还需要更新一下用户的登录状态。

　　在没有 Redux 之前，我都会写一个 service 来管理应用的状态。在这个模块里写上些 setter、getter 方法来存储状态的值，并根据业务功能写上一些来操作这个值。然而，使用 service 时，我们很难跟踪到状态的变化情况，还需要做一些额外的代码来特别处理。

　　有时候也会犯懒一下，直接写一个全局变量。这个时候维护起代码来就是一场噩梦，需要全局搜索相应的变量。如果是调用某个特定的 Service 就比较容易找到调用的地方。