这篇文章发布于 2018年04月24日，星期二，22:49，归类于 js实例。 阅读 1363 次, 今日 81 次
by zhangxinxu from www.zhangxinxu.com/wordpress/?…
本文可全文转载，但需要保留原作者和出处，摘要引流则随意。
Service Worker提供了一种能力，可以fetch请求的资源，然后后Service Worker中进行编译或转化，返回处理后的其他资源，这种特性可以用来实现各种资源的在线的客户端编译，本文就将抛砖引玉，通过两个应用案例，展示未来web开发可能的面貌。
一、Service Worker与直接数据和HTML模板渲染页面
现在很多网站的页面是基于Node.js直接渲染输出的，以实现完全的前后端分离，而这种渲染本质上还是在服务端进行的，只是渲染的语言是JavaScript。
实际上，有了Service Worker，我们可以直接在客户端，也就是浏览器里面直接进行渲染，优点是……乍一想，其实没什么特别的优点，无非是传输的HTML页面的体积小了，不过这点优化的体积就像是隔靴搔痒，杯水车薪，不值一提。但后来有一想，不对啊，这HTML编译全在客户端执行，岂不是省了很多服务器，为公司省了很多钱，因为烧的都是用户的电。
而且，毕竟是另外的一种解决思路，保不准某些场景下能大放异彩呢，抛砖引玉嘛，重在能力展示。
我们先看实际例子，您可以狠狠地点击这里：Service Worker与客户端渲染HTML渲染页面demo
打开一看，就是个列表，而且数据还是2012年北京蔬菜价格什么鬼？首先，数据什么的不是重点，只从为了节约时间从这篇文章“基于HTML模板和JSON数据的JavaScript交互”弄过来的，
这个页面玄机的要看开发文件源代码才行（右键页面源代码都不行）：github.com/zhangxinxu/…
可以看到，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(/([\w\W]*?)<\/script>/, function (matchs, $1) { // 获取页面渲染的JSON数据 data = JSON.parse($1); return ''; }); // 模板text和数据data进行渲染并重新返回给浏览器 return new Response(template.compile(text)(data), { headers: { 'content-type': 'text/html; charset=utf-8' } }); } return fetch(event.request); }()); });
也就是变量text是原始的HTML代码，而在Service Worker中返回的是template.compile(text)(data)渲染后的HTML代码，于是，浏览器中呈现的就是最终的列表数据而非原始模板HTML。
在本demo中，我是将页面需要的JSON数据放在了模板页面头部，并使用<script type="text/json">进行标示，截图如下：
sw-reader.js中就是匹配<script type="text/json">获取JSON数据来进行渲染的。当然，你也可以使用其他标识，例如，前后都3个美元符号包起来进行识别，例如：
?${
list: []
}?$就是不怎么雅观。OK，小例子，抛砖引玉，下面看另外一个对静态资源进行编译的例子。
二、Service Worker与浏览器直接CSS编译
CSS一些预编译工具，例如，Less，Stylus都是使用JavaScript进行编译的，而这些编译工具都是有web版的，因此，理论上我们是可以把Less，Stylus的编译直接搬到浏览器客户端里面，然后我们就不用加载CSS文件了，直接加载less文件，Service Worker中编译成CSS并返回，页面也是可以正常访问的。
然后，问题在于，Less，Stylus的web版解析器体积有些大，压缩后还有150多K，个人觉得成本有点高了。
为了快速书写，我自己弄了个名为Qcss的编译工具，可以讲CSS声明自定义为缩写，以实现写CSS代码如马踏飞燕，例如：
.class-a { dib; w100; tc; }可以实时转换成：
.class-a {
display: inline-block;
width: 100px;
text-align: center;
}而这个编译的JS方法提及非常小，仅2K多一点，和less的JS代码量相比简直就是毛毛雨，因此非常使用用在Service Worker实现一个可以在线编译CSS的功能。
先看例子，您可以狠狠地点击这里：Qcss和Service Worker在浏览器中编译成CSS demo
我们打开控制台查看网络请求，会发现，页面请求的是qcss文件，而不是传统的css文件：
而这个qcss文件原始代码是这样的：
全是一些CSS属性和属性值的缩写，但是，我们在demo页面查看qcss.test的请求数据，却是正统的CSS代码，截图示意如下：
同样的，也是Service Worker在浏览器背后编译的功劳，注册Service Worker的JS文件的核心代码如下：
var qcss=function(b){ /*qcss编译为css方法* /};
self.addEventListener('fetch', function(event) {
event.respondWith(async function () {
if (/\.qcss/.test(event.request.url)) {
let res = await fetch(event.request);
let text = await res.text();
return new Response(qcss(text), {
headers: {
'content-type': 'text/css; charset=utf-8'
}
});
}
return fetch(event.request);
}());
});对吧，通俗易懂，一路了然。
这种在线编译有什么好处呢？例如省流量，test.qcss文件为7K多，而test.css文件则14K多，相比传统CSS文件传输体积小了50%，注意，这已经是压缩后的CSS再减小50%体积，根据自己测试，减小的体积在30%~50%之间（选择器越简洁压缩率越高）。
想想看，要是公司产品所有CSS都变成Qcss，传输小30%~50%，估计可以给公司省不少流量钱。
为此，我特意又写了个Node.js工具，可以把CSS文件转换成QCSS文件：github.com/zhangxinxu/…
一个压缩器，一个解析器，外加Service Worker，就可以颠覆目前的CSS资源加载策略，对于一些无关紧要的小项目活动页面之类的，大家其实可以试试这种新技术，验证其价值。
关于QCSS解析及压缩，以后时机成熟我会专门介绍，这里，抛砖引玉，为大家的技术选项实践提供更开阔的思路。
三、Service Worker与浏览器直接JS编译
例如，我们可以把CoffeeScript直接搬到浏览器中，与上面类似，这里不进一步展开。
四、结束语
理论上，有了Service Worker，我们可以把很多很多Node.js的能力搬到客户端搬到浏览器中，不仅仅是离线缓存，不仅仅是模拟并伪造ajax请求数据，可谓是有了Service Worker，真的可以为所欲为。
有了技术能力，剩下的就是发挥我们的创造力和想象力，让我们的web开发策略更加繁荣昌盛。
还是那句话，本文旨在抛砖引玉，本文提供的两个demo的技术策略并不一定是最优解，也并不一定适合实际项目，尤其大型项目，可能会有风险。也欢迎大家集思广益，提供更好更佳的相关事件，我会在文中及时进行更新。
以上~
感谢阅读！
