精读《Caches API》

2023年5月15日 159次阅读 来源: 黄子毅

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：

  1. 翻开页面时，应用 web worker 挪用 react-dom/server 组织一个 SSR 字符串。
  2. 应用 caches.put 增加当前页面缓存，将 react-root 部份塞入组织好的 SSR 字符串。
  3. 下次翻开页面时，优先掷中缓存，似乎是后端供应了 SSR 效劳，但实在效劳是由上一次浏览器供应的。

前端衬着有几个优点：

  1. 不斲丧效劳器盘算资本，假如页面有百万 UV，能够一天就可以节约几十万元效劳器电费。
  2. 不斲丧效劳器存储资本，假如页面是千人千面的，后端 SSR 存储本钱庞大，但分摊到个人电脑就不成问题。
  3. 不须要写两套代码。虽然效劳端衬着反复应用前端资本，但 DOM 环境等都是模仿出来的，且前端代码还存在内存泄漏风险，很多 SSR 的前端代码必需推断前后端环境，给保护造成了庞大累赘。在前端衬着下这不成问题，我们的标语是：前端代码请交给浏览器实行。

笔者将这套前端衬着才能封装在
前端工程化东西 Pri 中，开启设置项
useServiceWorker=true
clientServerRender=true 尝试。

背面有时机零丁选一篇精读引见 前端衬着，你也能够直接参考笔者 大略的完成：因为 service worker 必需存在一个实体文件，因而脚手架会自动天生它，所以你看到的运转代码是一堆字符串。

4 总结

前端衬着是一个较为极度的例子，caches 更多用来缓存简朴的静态页面，静态博文，或许不常常更改的后端接口。

留下一个思考题：你还能想到 caches 的其他用法吗？迎接留言。

议论地点是：
精读《Caches API》 · Issue #124 · dt-fe/weekly

假如你想介入议论，请点击这里，每周都有新的主题，周末或周一宣布。前端精读 – 帮你挑选靠谱的内容。

    原文作者：黄子毅
    原文地址: https://segmentfault.com/a/1190000017878038
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞