Веб-API fetch невероятно прост (по сравнению со своим предшественником: XMLHttpRequest), но во время разработки у меня всегда есть несколько проблем, которые возникают при выполнении запросов на выборку: превышение ограничений сторонних запросов, задержка (поскольку я хочу, чтобы разработчик работал быстро) и потенциал переход в автономный режим (также известный как разработка в поездах).

Поскольку браузер - прекрасная вещь, я могу обернуть fetch API своей собственной логикой и обойти эти проблемы, поэтому я представляю вам: memfetch

Что оно делает

Memfetch ненавязчиво обернет API извлечения и кеширует любой запрос и ответ, чтобы, если у вас снова будет тот же самый запрос, он будет обслуживаться из локального кеша браузера. .

Важно отметить, что в моем коде нет изменений, позволяющих использовать кешированную версию запросов. Этот аспект - важная особенность для меня, потому что я рассматриваю memfetch как инструмент разработки, который я могу удалить без рефакторинга кода перед производством.

Как это использовать

Опять же, никаких изменений в моих запросах на выборку JavaScript, только чтобы включить библиотеку memfetch перед запуском моего кода:

<script src="https://unpkg.com/memfetch"></script>

Теперь все запросы на выборку будут кэшироваться, а последующие запросы будут обслуживаться непосредственно из локального хранилища браузера. Важно отметить, что запросы отпечатываются с использованием URL-адреса и параметров инициализации, передаваемых в fetch. Это означает, что если вашему запросу передана дополнительная опция (например, добавление mode: 'cors'), memfetch будет рассматривать ее как отдельную.

Опять же, все запросы на выборку кэшируются, включая POST запросов. Я подозреваю, что в будущем у меня будет какая-нибудь конфигурация _8 _ / _ 9_, если она будет востребована.

Чтобы очистить локальный кеш, в методе fetch есть свойство seed, если для него установлено значение, отличное от текущего значения (т. Е. Изменено с undefined на a или с a на b), локальный кеш будет полностью очищен:

Под капотом

Первоначально эта библиотека оборачивала fetch API и возвращала new Proxy, который позволял бы захватывать memfetch, что в коде использовался метод .json или .blob, но оказалось, что я мог упростить код и отказаться от использования прокси (так же круто, как они являются).

Исходный метод fetch сохраняется во внутреннем методе и заменяется оболочкой.

Когда код делает запрос, в IndexedDB сохраняется следующее (благодаря библиотеке micro idb-keyval Джейка Арчибальда):

  • url
  • варианты получения
  • заголовки ответа
  • статус
  • statusText
  • капля

Используя эти значения, memfetch создает new Response и возвращает тот вместо исходного ответа.

Последующие запросы проверяют, есть ли кэшированное значение, и, используя захваченные точки данных (см. Выше), оно разрешается с помощью другого new Response - таким образом авторский код может вызывать .blob или .json или любой другой метод, реализованный API ответа (что означало, что memfetch не работал) не нужно использовать прокси-объект).

Изначально опубликовано в B: log Реми Шарпа