摘要：引言这个是针对的。一般结合使用，因为请求级别的缓存与具有页面拦截功能的最配。本周精读的文章是，介绍了浏览器缓存接口的基本语法。包含任意命名空间，可以通过创建或访问。精读笔者利用实现了纯浏览器端的后端渲染。前端精读帮你筛选靠谱的内容。
1 引言
caches 这个 API 是针对 Request Response 的。caches 一般结合 Service Worker 使用，因为请求级别的缓存与具有页面拦截功能的 Service Worker 最配。
本周精读的文章是 cache-api，介绍了浏览器缓存接口的基本语法。
2 概述浏览器拥有全局变量 caches 操作缓存。
caches 包含任意命名空间，可以通过 caches.open 创建或访问。
const myCache = await caches.open("myCache");
添加缓存
通过 add 添加缓存。由于 caches 缓存是基于请求的，因此参数可以是一个 URL 地址，或一个完整的 Request 对象：
// URL only
myCache.add("/subscribe");
// Full request object
myCache.add(new Request("/subscribe", {
method: "GET",
headers: new Headers({
"Content-Type": "text/html"
}),
/* more request options */
});
每执行 add 时，浏览器都会主动请求并缓存返回的 Response。
可以通过 addAll 批量添加缓存：
myCache.addAll(["/subscribe", "/assets/images/profile.png"]);读取缓存
通过 match 读取缓存。与 add 类似，参数可以是 URL 地址或完整 Request 对象，同时支持 matchAll：
const res = await myCache.match("/subscribe");
更新缓存
通过 add 或 put 更新缓存。
当某个请求缓存需要更新时，你可以重新执行 add 操作。
同时 put 也可以更新缓存，你可以手动构造返回值，这样浏览器就不需要发请求了：
const request = new Request("/subscribe");
const fetchResponse = await fetch(request);
myCache.put(request, fetchResponse);
销毁缓存
通过 delete 销毁缓存。
你可以销毁某个路径的缓存：
myCache.delete("/subscribe");
也可以销毁某个缓存命名空间：
caches.delete("myCache");
结合 service Worker
可以利用 addEventListener("fetch") 监听浏览器请求时机，并在匹配到缓存时，直接替换为返回结果，当缓存不存在时才继续发请求。
self.addEventListener("fetch", (e) => {
e.respondWith(
// Check if item exists in cache
caches.match(e.request).then((cachedResponse) => {
// If found in cache, return cached response
if (cachedResponse) return cachedResponse;
// If not found, fetch over network
return fetch(e.request);
});
);
});
3 精读
笔者利用 caches API + service worker 实现了纯浏览器端的后端渲染。
首先基于下面三个基本事实：
利用 service worker 可以拦截请求。
caches 可以主动 put 修改缓存。
react-dom/server 可以在浏览器端执行。
这三个能力组合一下，我们真的可以实现前端 SSR：
打开页面时，利用 web worker 调用 react-dom/server 构造一个 SSR 字符串。
利用 caches.put 添加当前页面缓存，将 react-root 部分塞入构造好的 SSR 字符串。
下次打开页面时，优先命中缓存，仿佛是后端提供了 SSR 服务，但其实服务是由上一次浏览器提供的。
前端渲染有几个好处：
不消耗服务器计算资源，如果页面有百万 UV，可能一天就能节省几十万元服务器电费。
不消耗服务器存储资源，如果页面是千人千面的，后端 SSR 存储成本巨大，但分摊到个人电脑就不成问题。
不需要写两套代码。虽然服务端渲染重复利用前端资源，但 DOM 环境等都是模拟出来的，且前端代码还存在内存泄露风险，许多 SSR 的前端代码必须判断前后端环境，给维护造成了巨大负担。在前端渲染下这不成问题，我们的口号是：前端代码请交给浏览器执行。
笔者将这套前端渲染能力封装在 前端工程化工具 Pri 中，开启配置项 useServiceWorker=true clientServerRender=true 尝试。
后面有机会多带带选一篇精读介绍 前端渲染，你也可以直接参考笔者 简陋的实现：由于 service worker 必须存在一个实体文件，因此脚手架会自动生成它，所以你看到的运行代码是一堆字符串。
4 总结前端渲染是一个较为极端的例子，caches 更多用来缓存简单的静态页面，静态博文，或者不经常变动的后端接口。
留下一个思考题：你还能想到 caches 的其他用法吗？欢迎留言。
讨论地址是：精读《Caches API》 · Issue #124 · dt-fe/weekly
如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/101002.html
摘要：概述的解释器优化器代码可能在字节码或者优化后的机器码状态下执行，而生成字节码速度很快，而生成机器码就要慢一些了。比如有一个函数，从获取值引擎生成的字节码结构是这样的指令是获取参数指向的对象，并存储在，第二步则返回。 1 引言 本期精读的文章是：JS 引擎基础之 Shapes and Inline Caches 一起了解下 JS 引擎是如何运作的吧！ JS 的运作机制可以分为 AST 分...
摘要：引言本周精读的文章是，看看作者是如何解释这个多态性含义的。读完文章才发现，文章标题改为的多态性更妥当，因为整篇文章都在说，而使用场景不局限于。更多讨论讨论地址是精读的多态性如果你想参与讨论，请点击这里，每周都有新的主题，周末或周一发布。 1 引言 本周精读的文章是：surprising-polymorphism-in-react-applications，看看作者是如何解释这个多态性含...
摘要：拿到的都是而不是原始值，且这个值会动态变化。精读对于的与，笔者做一些对比。因此采取了作为优化方案只有当第二个依赖参数变化时才返回新引用。不需要使用等进行性能优化，所有性能优化都是自动的。前端精读帮你筛选靠谱的内容。 1. 引言 Vue 3.0 的发布引起了轩然大波，让我们解读下它的 function api RFC 详细了解一下 Vue 团队是怎么想的吧！ 首先官方回答了几个最受关注的...
摘要：举例来说即便某个失败了，也不会导致的发生，这样在不在乎是否有项目失败，只要拿到都结束的信号的场景很有用。对于则稍有不同只要有子项，就会完成，哪怕第一个了，而第二个了，也会，而对于，这种场景会直接。 1. 引言 本周精读的内容是：Google I/O 19。 2019 年 Google I/O 介绍了一些激动人心的 JS 新特性，这些特性有些已经被主流浏览器实现，并支持 polyfill...
摘要：调度系统，支持不同渲染优先级，对进行调度。调度带来的限制调度系统也存在两个问题。调度系统能力有限，只能在浏览器提供的能力范围内进行调度，而无法影响比如的渲染回收周期。精读关于调度系统的剖析，可以读深入剖析这篇文章，感谢我们团队的淡苍提供。 1. 引言 这次介绍的文章是 scheduling-in-react，简单来说就是 React 的调度系统，为了得到更顺滑的用户体验。 毕竟前端做到...
阅读 2374·2019-08-30 15:53
阅读 2763·2019-08-29 16:20
阅读 961·2019-08-29 15:10
阅读 891·2019-08-26 10:58
阅读 2076·2019-08-26 10:49
阅读 526·2019-08-26 10:21
阅读 587·2019-08-23 18:30
阅读 1541·2019-08-23 15:58
