这篇文章发布于 2018年04月24日,星期二,22:49,归类于 JS实例。 阅读 36496 次, 今日 4 次 15 条评论
by zhangxinxu from http://www.zhangxinxu.com/wordpress/?p=7488
本文可全文转载,但需要保留原作者和出处,摘要引流则随意。
Service Worker提供了一种能力,可以fetch请求的资源,然后后Service Worker中进行编译或转化,返回处理后的其他资源,这种特性可以用来实现各种资源的在线的客户端编译,本文就将抛砖引玉,通过两个应用案例,展示未来web开发可能的面貌。
一、Service Worker与直接数据和HTML模板渲染页面
现在很多网站的页面是基于Node.js直接渲染输出的,以实现完全的前后端分离,而这种渲染本质上还是在服务端进行的,只是渲染的语言是JavaScript。
实际上,有了Service Worker,我们可以直接在客户端,也就是浏览器里面直接进行渲染,优点是……乍一想,其实没什么特别的优点,无非是传输的HTML页面的体积小了,不过这点优化的体积就像是隔靴搔痒,杯水车薪,不值一提。但后来有一想,不对啊,这HTML编译全在客户端执行,岂不是省了很多服务器,为公司省了很多钱,因为烧的都是用户的电。
而且,毕竟是另外的一种解决思路,保不准某些场景下能大放异彩呢,抛砖引玉嘛,重在能力展示。
我们先看实际例子,您可以狠狠地点击这里:Service Worker与客户端渲染HTML渲染页面demo
打开一看,就是个列表,而且数据还是2012年北京蔬菜价格什么鬼?首先,数据什么的不是重点,只从为了节约时间从这篇文章“基于HTML模板和JSON数据的JavaScript交互”弄过来的,
这个页面玄机的要看开发文件源代码才行(右键页面源代码都不行):https://github.com/zhangxinxu/https-demo/tree/master/online-render
可以看到,index.html
文件源代码列表明明是模板语法:
但是我们右键页面,查看HTML源代码的时候确是真实的列表内容:
为什么会发生这么神奇的事情?玄机就是Service Worker在背后做了HTML的数据渲染。
首先,注册Service Worker,代码如下:
if ('serviceWorker' in navigator) { navigator.serviceWorker.register('./sw-reader.js', { scope: './' }); }
然后关键就是sw-reader.js
(访问点击这里),做了两件事情:
- 内置极简模板渲染引擎,采用的是老版本的artTemplate,大小仅2.3K。截图如下:
- 捕获
.html
的请求,并对获取到的的HTML字符内容进行模板渲染,并返回输出。完成JS代码如下:self.addEventListener('fetch', function(event) { event.respondWith(async function () { if (/\.html/.test(event.request.url)) { let res = await fetch(event.request); let text = await res.text(); var data = {}; // 过滤JSON数据,使不暴露给用户 text = text.replace(/ -->
发表评论(目前15 条评论)
旭大神,可以分享一下浏览器渲染页面的流程吗?往上每次查资料,感觉写的都不是很靠谱呀
666.学到了.
兼容性貌似还存在点问题
嗯,看着你右上角的广告轮播图超烦人的,又不能关掉。
于是F12审查元素,把那一段代码删掉了。
嗯,这下干净了,继续看。
文章很不错,之前也想过,不过美中不足的是,SEO依然不行,百度不会解析JS部分,按照渲染完的内容去收录建立索引。
get
用着东西渲染,会影响百度收录吗
就怕移动端跑不动
了解了….
留下,学一会
关注下,万一火了呢
https://zhangxinxu.github.io/https-demo/online-render/
https://zhangxinxu.github.io/https-demo/online-render/index.html
为什么第一个链接没有渲染。。
https://zhangxinxu.github.io/https-demo/online-render/index.html 完整URL访问,因为demo是判断的.html后缀处理的。
赞
错别字:
为了快速书写,我自己弄了个名为Qcss的编译工具,可以→讲←CSS声明自定义为缩写