客户端渲染有哪些坑?

标签: MVVM 异步渲染 路由 兼容性 pushState | 发表时间:2017-10-28 08:00 | 作者:Harttle
出处:http://harttle.com/

从别的角度出发,客户端渲染有很多其他名字比如前端渲染、前端异步、前端 MVC。 今天的 Web 稍有交互的站点都会做一套前端渲染,从早期的 Backbone,AngularJS 1.0, 到现在的流行的 Vue,React。基于这些技术做 MVVM 的同时甚至可以完成服务器端渲染。 但浏览器的客户端渲染(也就是前端 MVC)仍然存在不少限制,这些限制都是前端渲染绕不过的问题。

概述

一个支持客户端渲染的技术架构应当包括这些内容:

  • 首屏渲染。服务器端渲染首屏,或者客户端根据当前 URL 渲染对应的页面。
  • 前端路由。点击链接时改变页面的 URL,返回/前进时渲染对应页面。
  • 异步渲染。在不发生整页重新载入的情况下更新页面内容。

下文中,我们用 同步渲染 指代浏览器直接载入 HTML 及其中的资源;用 异步渲染 指通过 DOM API 去动态插入元素和资源。

共享同一个后端服务

结论:异步打开的所有 URL 都必须在同一服务器,或者这些服务器都知道所有 URL 对应的页面信息。

场景:打开页面A -> 跳转到页面 B -> 刷新 -> 返回到页面 A。考虑如何渲染页面 A?

对于传统的同步渲染,构成 Web 站点的页面之间不需共享任何信息,一个链接就足够了。 但对于一部打开的页面,没有对方页面的信息就意味着无法异步渲染。

在同构渲染流行之前,通常的实现是让服务器对所有页面都返回同样的内容:框架页面。 前端路由会根据页面 URL (最初还是使用 hash 部分)从这个框架页面渲染出真正的页面。 因此那个框架页面知道所有可能的页面如何渲染。

显然上述实现搜索引擎不友好,首屏时间延迟。同构渲染技术使得服务器可以直接渲染用户请求的那个页面,而不需要先在客户端启动 MVC 框架。但即使是同构渲染,仍然要求一个服务器知道所有可能会异步打开的页面。

这一限制从某个角度上理解是反 Web 的。Web 是开放互联的同时服务器之间完全独立,正是这一点让 Web 变得 Scalable。客户端渲染让一组页面对应同一个后端服务,它们组成一个前端 App。

脚本要符合异步风格

结论:所有页面的脚本都必须无副作用、不依赖 <script> 顺序。

场景:两个页面间异步切换时,对应脚本能够多次执行和卸载。

同步渲染中,所有全局变量、定时器、事件监听器会在一个 Reload 后完全消失,而异步页面则不然。 如果一个脚本依赖于(读写)全局变量,那么多次载入后它的行为可能会发生异常。 比如一个交互统计脚本多次载入后可能会重复计数,因为它每次载入都产生一个事件监听器。

如果一个异步页面有多个 <script>,在 异步渲染时脚本的执行顺序 是不保证的。 这一点与 浏览器同步渲染 完全不同。 因此可能需要类似 RequireJS 之类的模块加载器。

为了解决上述问题,多数前端 MVVM 框架都不建议直接在 HTML 中插入 <script> 来编写业务代码。 与此相反,会提供类似 模块组件 之类的概念来托管脚本的执行。

PushState API 不完善

结论:浏览器的路由相关 API 能力较弱且存在兼容性问题。

场景:在用户点击链接时,需要操作 URL;在用户点击浏览器返回/前进时,需要渲染页面。

HTML5 中定义了 pushState API,包括 pushState 方法replaceState 方法popstate 事件。 我们不谈这些 API 的设计,只看它们的奇怪行为:

  • 同步渲染的页面资源 加载会延迟 popstate 事件。这使得页面未加载完时可以点出但无法返回。
  • pushState 调用不会触发 popstate 事件。通常需要一个路由工具来包装这些不一致。
  • PopStateEvent.state 总是等于 history.state。无法获取被 pop 出的 state。
  • popstate 事件处理函数中无法区分是前进还是后退。考虑刷新页面的场景不能只存储为变量,只能存储在 sessionStorage 中,但这无疑会增加路由的延迟。
  • 有些浏览器不支持 history.state,但支持 pushStatepopstate

相关 [客户端 渲染] 推荐:

客户端渲染有哪些坑?

- - Harttle Land
从别的角度出发,客户端渲染有很多其他名字比如前端渲染、前端异步、前端 MVC. 今天的 Web 稍有交互的站点都会做一套前端渲染,从早期的 Backbone,AngularJS 1.0, 到现在的流行的 Vue,React. 基于这些技术做 MVVM 的同时甚至可以完成服务器端渲染. 但浏览器的客户端渲染(也就是前端 MVC)仍然存在不少限制,这些限制都是前端渲染绕不过的问题.

MongoDB 客户端 MongoVue

- - haohtml's blog
今天在同事那里看到了一个很不错的MongoDB的客户端工具MongoVue,地址是 http://www.mongovue.com/. 做的不错,1.0版本的开始收费了,费用也不贵才35$. 真正需要的同学可以掏点钱买个吧,也算是支持这个工具,如果只是学习研究用的话我这里还有一个0.9.7版本,虽然比起1.0版来说有些bug,平常使用也够了,需要的同学可以单独联系我.

[转]memCached 客户端

- - 小鸥的博客
memcache客户端下载. 许多Web应用都将数据保存到DBMS中,应用服务器从中读取数据并在浏览器中显示. 但随着数据量的增大、访问的集中,就会出现RDBMS的负担加重、数据库响应恶化、 网站显示延迟等重大影响. memcached 是以LiveJournal 旗下Danga Interactive 公司的Brad Fitzpatric 为首开发的一款软件.

客户端·优化

- - 博客园_首页
网络连接和初始HTTP请求. 浏览器检索网页,先从URL开始,使用DNS确定IP地址,再用基于TCP和HTTP协议连接到服务器,请求相关的内容,得到相应,浏览器解析并呈现到屏幕上. 服务器响应后,浏览器响应不会同时全部到达,会陆续到达,有时候之间还会有时间间隔. 页面解析和新的资源请求浏览器等待数据包时,会解析得到包,并寻找可用新的HTTP请求,并启动,每一个服务器,浏览器一般最多同时打开两个请求连接.

BitCoin for Ubuntu 11.04 客户端

- Riku - Wow! Ubuntu
BitCoin 最近很热,大量的媒体、Blog ,甚至叽喳上都在谈论此物. 那么 BitCoin 到底为何物. [以下引用自 ivarptr 的文章,详情请看“通俗易懂讲解什么是 Bitcoin 虚拟货币”一文]. Bitcoin (为了便于书写和理解,下面如果是表示 “Bitcoin币”意思的地方我称呼其为“贝壳币”,取粤语相近的音译)是一种网络虚拟货币,跟腾讯公司的Q币类似,你可以使用贝壳币购买一些虚拟的物品,比如网络游戏当中的衣服、帽子、装备等,只要有人接受,你也可以使用贝壳币购买现实生活当中的物品.

GClient – Google+ 桌面客户端

- 闷闲居士 - 软件街
就是一个SNS社交网站,在这个社交网站上你可以和不同兴趣的好友分享好玩的东西. Google+ 在网络上占着举足轻重的地位,G粉整天挂着浏览器,随时观看有没有新的通知,这样还是蛮累滴,如果有G+桌面客户端那多方便. 没错就是有这么一款 Google+ 桌面工具:GClient,支持通知新信息,还可以直接在桌面玩转Google+ ….

叽喳客户端 Polly

- We_Get - Wow! Ubuntu
Linux 平台上的叽喳客户端我们介绍过很多,比如 Hotot ,Pino,Twip 等等. 现在要介绍的 Polly 是款全新的叽喳客户端,目前还处于 pre-alpha 阶段,它的主要功能如下:. 与 Messaging Menu 整合. # Ubuntu 11.04 及 11.10 用户安装.

浏览器如何渲染文本

- old9 - jjgod / blog
浏览器是我们最常用的软件之一,文本又是网页中最主要的元素,在浏览器显示文本的过程中有许多有趣的细节,值得展开来讲讲,或许能减少一些误解. 这是一个比较粗略的,概括性的介绍,尽可能不涉及过多的技术细节和具体实现,而立足于给 Web 开发者和设计师提供一些正确的概念. 下面的介绍主要根据我对 WebKit 和 Gecko (Firefox) 的印象来谈,其他的浏览器也大致相同,如有阙漏之处欢迎指出.

“浏览器渲染原理”PPT

- zhibin - 宅居
这是今天一次内部分享的PPT,其中内容主要来自于Winter大大分享的相关材料,和How Browser Work这一文的一些内容. 由于内部分享是以讲为主,因此PPT并不包含所有内容,仅仅是一个摘要的形式,另有以下几点:. 由于是在MAC下制作的,在Windows下播放可能由于字体等原因,造成排版错乱,请自行脑补或调整.

浏览器如何渲染文本

- - ITeye博客
浏览器是我们最常用的软件之一,文本又是网页中最主要的元素, 在浏览器显示文本的过程中有许多有趣的细节,值得展开来讲讲,或许能减少一些误解. 这是一个比较粗略的,概括性的介绍,尽可能不涉及过多的技术细节和具体实现,而立足于给 Web 开发者和设计师提供一些正确的概念. 下面的介绍主要根据我对 WebKit 和 Gecko (Firefox) 的印象来谈,其他的浏览器也大致相同,如有阙漏之处欢迎指出.