تعديلات على cache.addAll() وImportScripts() لإدخال التعديلات في الإصدار Chrome 71

Jeff Posnick

على مطوّري البرامج الذين يستخدمون عاملي الخدمات وواجهة برمجة تطبيقات ذاكرة التخزين المؤقت الاطّلاع على تغييرين صغيرين سيتم طرحهما في الإصدار Chrome 71. يؤدي كلا التغييرَين إلى جعل تنفيذ Chrome أكثر توافقًا مع المواصفات والمتصفّحات الأخرى.

عدم السماح باستيراد دالة importScripts() غير متزامنة

يطلب العنصر importScripts() من نص worker الرئيسي للخدمت إيقاف تنفيذه الحالي مؤقتًا وتنزيل رمز إضافي من عنوان URL معيّن وتنفيذه إلى أن يكتمل في النطاق الشامل الحالي. بعد الانتهاء من ذلك، يستأنف النص البرمجي الرئيسي لعامل الخدمة تنفيذه. يمكنك استخدام importScripts() عندما تريد تقسيم النص البرمجي الخاص بمشغِّل الخدمات الرئيسي إلى أجزاء أصغر لأسباب تنظيمية، أو يمكنك استخدام رمز تابع لجهة خارجية لإضافة وظائف إلى مشغّل الخدمات.

تحاول المتصفّحات الحدّ من مشاكل الأداء المحتمَلة الناتجة عن "تنزيل بعض الرموز البرمجية المتزامنة وتشغيلها" من خلال التخزين المؤقت لأي عنصر يتم سحبه من خلال importScripts() بشكل مؤقت، ما يعني أنّه بعد عملية التنزيل الأوّلية، ستتتطلّب عملية تنفيذ الرموز البرمجية المستوردة قليلاً من الاستخدام.

لكي يعمل ذلك، يجب أن يعرف المتصفّح أنّه لن يتم استيراد أي رمز "مفاجئ" إلى الخدمة العاملة بعد التثبيت الأوّلي. وفقًا لمواصفات موظّف الخدمة، من المفترض أن لا يعمل importScripts() إلا أثناء التنفيذ المتزامن لنص موظّف الخدمة العميق، أو بشكل غير متزامن داخل معالِج install إذا لزم الأمر.

قبل الإصدار 71 من Chrome، كان من الممكن الاستدعاء غير المتزامن importScripts() خارج معالِج install. بدءًا من الإصدار 71 من Chrome، تؤدي هذه الطلبات إلى طرح استثناء وقت التشغيل (ما لم يتم استيراد عنوان URL نفسه سابقًا في معالِج install)، ما يتطابق مع السلوك في المتصفّحات الأخرى.

بدلاً من رمز مثل هذا:

// This only works in Chrome 70 and below.
self.addEventListener('fetch', event => {
  importScripts('my-fetch-logic.js');
  event.respondWith(self.customFetchLogic(event));
});

يجب أن يبدو رمز العامل في الخدمة على النحو التالي:

// Move the importScripts() to the top-level scope.
// (Alternatively, import the same URL in the install handler.)
importScripts('my-fetch-logic.js');
self.addEventListener('fetch', event => {
  event.respondWith(self.customFetchLogic(event));
});

إيقاف عناوين URL المتكرّرة التي يتم تمريرها إلى cache.addAll() نهائيًا

إذا كنت تستخدم واجهة برمجة التطبيقات Cache Storage API مع مشغّل خدمات، هناك تغيير بسيط آخر في Chrome 71 للتوافق مع المواصفات ذات الصلة. عندما يتم إرسال عنوان URL نفسه عدة مرات إلى طلب واحد لمحاولة cache.addAll()، تنص الموافقة على أنّه يجب رفض الوعد الذي تم إرجاعه من خلال الطلب.

قبل الإصدار 71 من Chrome، لم يتم رصد ذلك، وكان يتم تجاهل عناوين URL المكرّرة بشكلٍ فعال.

هذه الميزة هي تمهيد لإصدار Chrome 72، حيث ستؤدي عناوين URL المكرّرة إلى cache.addAll() رفض بدلاً من مجرد تحذير مسجّل. إذا كنت تستدعي cache.addAll() كجزء من سلسلة وعد تم تمريرها إلى InstallEvent.waitUntil()، قد يؤدي هذا الرفض إلى تعذُّر تثبيت مشغّل الخدمة، كما هو شائع.

في ما يلي الخطوات التي قد تواجهك فيها:

const urlsToCache = [
  '/index.html',
  '/main.css',
  '/app.js',
  '/index.html', // Oops! This is listed twice and should be removed.
];

self.addEventListener('install', event => {
  event.waitUntil(
    caches.open('my-cache').then(cache => cache.addAll(urlsToCache))
  );
});

لا ينطبق هذا القيد سوى على عناوين URL الفعلية التي يتم تمريرها إلى cache.addAll()، ولن يؤدي التخزين المؤقت لما ينتهي به الأمر إلى ردين مكافئين لهما عنوانَي URL مختلفَين، مثل '/' و'/index.html'، لن يؤدي إلى رفض الإعلان.

اختبار تنفيذ الخدمة العاملة على نطاق واسع

تم تنفيذ مهام الخدمة على نطاق واسع في جميع المتصفّحات الرئيسية التي تعمل باستمرار في هذه المرحلة. إذا كنت تختبر تطبيقك الويب التقدّمي بانتظام على عدد من المتصفّحات، أو إذا كان لديك عدد كبير من المستخدمين الذين لا يستخدمون Chrome، من المرجّح أنّك رصدت التناقض وغيّرت الرمز البرمجي. ولكن في حال عدم ملاحظتك لهذا السلوك في المتصفّحات الأخرى، أردنا الإشارة إلى هذا التغيير قبل تغيير سلوك Chrome.