از من خواسته شده است که این پست را در یک بهروزرسانی نسبتاً جزئی به API کش سرویس کارگر بنویسم. فکر نمیکردم مقاله خودش را تضمین کند، اما پس از یک بحث طولانی که در نهایت به یک بازی سنگ-کاغذ-قیچی ختم شد، باختم، پس اینجاست.
آیا آماده شنیدن بهروزرسانیهای اجرای Chrome API کش سرویس کارگر هستید؟
نمیتونم بشنوم! گفتم، آیا آمادهاید در مورد بهروزرسانیهای اجرای Chrome API cache worker بشنوید؟
(فقط زمانی می توانید ادامه دهید که روی صندلی خود پریده باشید و فریاد زده باشید "YEAHHH!". تظاهر همزمان به تاب دادن کمند اختیاری است، اما تشویق می شود).
cache.addAll در Chrome 46 وارد شد
بله! درست است! کش! نقطه اضافه کردن همه! کروم 46!
بسیار خوب، طعنه به کنار، این در واقع یک معامله بسیار بزرگ است، زیرا cache.addAll
آخرین بخش باقیمانده از cache "ssentials" polyfill است، به این معنی که دیگر نیازی به آن نیست.
در اینجا نحوه کار cache.addAll
آمده است:
// when the browser sees this SW for the first time
self.addEventListener('install', function(event) {
// wait until the following promise resolves
event.waitUntil(
// open/create a cache named 'mysite-static-v1'
caches.open('mysite-static-v1').then(function(cache) {
// fetch and add this stuff to it
return cache.addAll([
'/',
'/css/styles.css',
'/js/script.js',
'/imgs/cat-falls-over.gif'
]);
})
);
});
addAll
آرایه ای از url ها و درخواست ها را می گیرد، آنها را واکشی می کند و به حافظه پنهان اضافه می کند. این تراکنشی است - اگر هر یک از واکشی یا نوشتن ناموفق باشد، کل عملیات با شکست مواجه می شود و حافظه پنهان به حالت قبلی خود باز می گردد. این به ویژه برای عملیات نصب مانند بالا مفید است، جایی که یک شکست باید یک شکست کلی باشد.
مثال بالا در یک سرویسکار است، اما API حافظه پنهان از صفحات نیز کاملاً قابل دسترسی است.
فایرفاکس در حال حاضر از این API در نسخه توسعهدهنده خود پشتیبانی میکند، بنابراین با بقیه پیادهسازی سرویسدهنده آنها همراه خواهد بود.
اما صبر کنید، این همه چیز نیست، بهبودهای حافظه پنهان بیشتری در خط لوله وجود دارد…
cache.matchAll به Chrome 47 می آید
این به شما امکان می دهد چندین مسابقه را دریافت کنید:
caches.open('mysite-static-v1').then(function(cache) {
return cache.matchAll('/');
}).then(function(responses) {
// …
});
موارد فوق همه چیزهایی را که در mysite-static-v1
مطابق با /
هستند را دریافت می کند. حافظه پنهان به شما امکان میدهد چندین ورودی در هر URL داشته باشید، اگر به طور مستقل قابل ذخیرهسازی هستند، به عنوان مثال اگر سرصفحههای Vary
متفاوتی داشته باشند.
فایرفاکس قبلاً از این در نسخه توسعهدهنده خود پشتیبانی میکند، بنابراین با بقیه اجرای سرویسکارگر آنها همراه خواهد بود.
گزینههای جستجوی حافظه پنهان به Chrome… به زودی
در اینجا یک کنترل کننده واکشی بسیار استاندارد وجود دارد:
self.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request).then(function(response) {
return response || fetch(event.request);
})
);
});
اگر ما /
ذخیره کرده ایم، و درخواستی برای /
دریافت می کنیم، از حافظه پنهان ارائه می شود. با این حال، اگر درخواستی برای /?utm_source=blahblahwhatever
هرچه که از حافظه پنهان نمی آید دریافت کنیم. میتوانید با نادیده گرفتن رشته جستجوی url در حین تطبیق، این مشکل را حل کنید:
self.addEventListener('fetch', function(event) {
event.respondWith(
caches.match(event.request, {
ignoreSearch: true
}).then(function(response) {
return response || fetch(event.request);
})
);
});
اکنون /?utm_source=blahblahwhatever
با ورودی برای /
مطابقت داده می شود! گزینه های کامل عبارتند از:
-
ignoreSearch
- نادیده گرفتن بخش جستجوی url هم در آرگومان درخواست و هم در درخواست های ذخیره شده در حافظه پنهان -
ignoreMethod
- روش آرگومان درخواست را نادیده بگیرید، بنابراین درخواست POST می تواند با ورودی GET در حافظه پنهان مطابقت داشته باشد. -
ignoreVary
- هدر variy را در پاسخهای کش نادیده بگیرید
فایرفاکس در حال حاضر از این در خود پشتیبانی می کند ... خوب شما قبلاً این تمرین را می دانید. برو به بن کلی بگو چقدر او برای وارد کردن همه اینها به فایرفاکس عالی است.
اگر میخواهید اجرای کروم از گزینههای جستجوی حافظه پنهان را دنبال کنید، crbug.com/426309 را بررسی کنید.
دفعه بعد شما را برای فصل هیجان انگیز دیگری از "آنچه در حافظه پنهان API پیاده سازی کردیم" می بینیم!