Веб-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 Реми Шарпа