ওয়ার্কবক্স v3 থেকে আপগ্রেড করার সময় আপনাকে কী পরিবর্তন করতে হবে তার উদাহরণ সহ এই নির্দেশিকাটি ওয়ার্কবক্স v4-তে প্রবর্তিত পরিবর্তনগুলি ভাঙার উপর দৃষ্টি নিবদ্ধ করে।
ব্রেকিং পরিবর্তন
ওয়ার্কবক্স-প্রেক্যাচিং
প্রিক্যাচেড এন্ট্রিগুলির নামকরণের নিয়ম আপডেট করা হয়েছে। এখন, এন্ট্রিগুলির জন্য যেগুলির URLগুলির পুনর্বিবেচনার তথ্যের প্রয়োজন হয় (অর্থাৎ প্রিক্যাশে ম্যানিফেস্টে একটি revision ক্ষেত্র ধারণ করে এমন এন্ট্রিগুলির জন্য), সেই সংস্করণ সংক্রান্ত তথ্যগুলি মূল URL-এর সাথে সংযুক্ত একটি বিশেষ __WB_REVISION__ URL ক্যোয়ারী প্যারামিটারে ক্যাশে কী-এর অংশ হিসাবে সংরক্ষণ করা হবে৷ (পূর্বে, IndexedDB ব্যবহার করে এই তথ্য ক্যাশে কী থেকে আলাদা সংরক্ষণ করা হয়েছিল।)
যে সকল ডেভেলপাররা workbox.precaching.precacheAndRoute() এর মাধ্যমে প্রিক্যাচিংয়ের সুবিধা গ্রহণ করেন, যেটি সবচেয়ে সাধারণ ব্যবহারের ক্ষেত্রে, তাদের পরিষেবা কর্মী কনফিগারেশনে কোনো পরিবর্তন করতে হবে না; Workbox v4-এ আপগ্রেড করার পরে, আপনার ব্যবহারকারীদের ক্যাশে করা সম্পদগুলি স্বয়ংক্রিয়ভাবে নতুন ক্যাশে কী বিন্যাসে স্থানান্তরিত হবে, এবং সামনের দিকে অগ্রসর হলে, পূর্বনির্ধারিত সংস্থানগুলি আগের মতোই পরিবেশিত হতে থাকবে৷
সরাসরি ক্যাশে কী ব্যবহার করা
কিছু ডেভেলপারকে workbox.precaching.precacheAndRoute() এর প্রেক্ষাপটের বাইরে সরাসরি প্রিক্যাচ এন্ট্রি অ্যাক্সেস করতে হতে পারে। উদাহরণ স্বরূপ, নেটওয়ার্ক থেকে একটি প্রকৃত ছবি আনা না গেলে আপনি একটি ইমেজ প্রিক্যাচ করতে পারেন যা আপনি "ফলব্যাক" প্রতিক্রিয়া হিসাবে ব্যবহার করেন।
ওয়ার্কবক্স v4 থেকে শুরু করে আপনি যদি এইভাবে প্রি-ক্যাচ করা সম্পদ ব্যবহার করেন, তাহলে ক্যাশে করা এন্ট্রি পড়ার জন্য ব্যবহার করা যেতে পারে এমন সংশ্লিষ্ট ক্যাশে কী-তে একটি মূল URL অনুবাদ করার জন্য আপনাকে একটি অতিরিক্ত পদক্ষেপ নিতে হবে। আপনি workbox.precaching.getCacheKeyForURL(originURL) কল করে এটি করতে পারেন।
উদাহরণস্বরূপ, যদি আপনি জানেন যে 'fallback.png' প্রিক্যাচ করা হয়েছে:
const imageFallbackCacheKey =
workbox.precaching.getCacheKeyForURL('fallback.png');
workbox.routing.setCatchHandler(({event}) => {
switch (event.request.destination) {
case 'image':
return caches.match(imageFallbackCacheKey);
break;
// ...other fallback logic goes here...
}
});
পুরানো প্রিক্যাচেড ডেটা পরিষ্কার করা
ওয়ার্কবক্স v4-এ প্রিক্যাচিং-এ করা পরিবর্তনগুলির অর্থ হল ওয়ার্কবক্সের পূর্ববর্তী সংস্করণগুলির দ্বারা তৈরি পুরানো প্রিক্যাচগুলি সামঞ্জস্যপূর্ণ নয়৷ ডিফল্টরূপে, সেগুলি যেমন আছে তেমনই থাকে, এবং আপনি যদি ওয়ার্কবক্স v3 থেকে ওয়ার্কবক্স v4 তে আপগ্রেড করেন, তাহলে আপনার সমস্ত পূর্বনির্ধারিত সংস্থানগুলির দুটি কপি থাকবে৷
এটি এড়াতে, আপনি একটি পরিষেবা কর্মীদের সরাসরি workbox.precaching.cleanupOutdatedCaches() এ কল যোগ করতে পারেন, অথবা GenerateSW মোডে একটি বিল্ড টুল ব্যবহার করলে নতুন cleanupOutdatedCaches: true বিকল্প সেট করতে পারেন। কারণ ক্যাশে ক্লিনআপ লজিক পুরানো প্রিক্যাচগুলি খুঁজে পেতে ক্যাশে নামকরণের নিয়মগুলিতে কাজ করে এবং যেহেতু বিকাশকারীদের কাছে সেই কনভেনশনগুলিকে ওভাররাইড করার বিকল্প থাকে, তাই আমরা নিরাপত্তার দিক থেকে ভুল করেছি এবং এটি ডিফল্টরূপে সক্ষম করিনি৷
আমরা ডেভেলপারদের উৎসাহিত করি যারা এটি ব্যবহার করে কোনো সমস্যায় পড়েন—যেমন মুছে ফেলার বিষয়ে মিথ্যা-পজিটিভ— আমাদের জানাতে ।
প্যারামিটার ক্যাপিটালাইজেশন
দুটি ঐচ্ছিক পরামিতি যা workbox.precaching.precacheAndRoute() এবং workbox.precaching.addRoute() এ পাস করা যেতে পারে, আমাদের সামগ্রিক ক্যাপিটালাইজেশন কনভেনশনকে প্রমিত করার জন্য পুনরায় নামকরণ করা হয়েছে। ignoreUrlParametersMatching এখন ignoreURLParametersMatching , এবং cleanUrls এখন cleanURLs ।
ওয়ার্কবক্স-কৌশল
workbox-strategies হ্যান্ডলারের একটি উদাহরণ তৈরি করার দুটি, মোটামুটি সমতুল্য উপায় রয়েছে। আমরা ফ্যাক্টরি পদ্ধতি অবমূল্যায়ন করছি, কৌশলটির কনস্ট্রাক্টরকে স্পষ্টভাবে কল করার পক্ষে।
// This factory method syntax has been deprecated:
const networkFirstStrategy = workbox.strategies.networkFirst({...});
// Instead, use the constructor directly:
// (Note that the class name is Uppercase.)
const networkFirstStrategy = new workbox.strategies.NetworkFirst({...});
যদিও ফ্যাক্টরি মেথড সিনট্যাক্স v4 তে কাজ করা চালিয়ে যাবে, এটি ব্যবহার করে একটি সতর্কতা লগ হবে এবং আমরা বিকাশকারীদের ভবিষ্যতের v5 রিলিজে সমর্থন সরিয়ে দেওয়ার আগে মাইগ্রেট করতে উৎসাহিত করি।
ওয়ার্কবক্স-ব্যাকগ্রাউন্ড-সিঙ্ক
workbox.backgroundSync.Queue ক্লাসটি ডেভেলপারদের আরও নমনীয়তা এবং সারিতে অনুরোধগুলি কীভাবে যোগ করা হয় এবং পুনরায় চালানো হয় তার উপর নিয়ন্ত্রণ দেওয়ার জন্য পুনরায় লেখা হয়েছে৷
v3 তে, Queue শ্রেণীতে সারিতে অনুরোধ যোগ করার একটি একক উপায় ছিল ( addRequest() পদ্ধতি), কিন্তু এটিতে সারি পরিবর্তন বা অনুরোধগুলি সরানোর কোনো উপায় ছিল না।
v4 এ, addRequests() পদ্ধতিটি সরানো হয়েছে, এবং নিম্নলিখিত অ্যারের মতো পদ্ধতি যোগ করা হয়েছে:
-
pushRequest() -
popRequest() -
shiftRequest() -
unshiftRequest()
v3 তে, Queue শ্রেণীটি বেশ কয়েকটি কলব্যাকও গ্রহণ করেছে যা আপনাকে অনুরোধগুলি পুনরায় চালানোর সময় পর্যবেক্ষণ করতে দেয় ( requestWillEnqueue , requestWillReplay , queueDidReplay ), কিন্তু বেশিরভাগ বিকাশকারীরা দেখেছেন যে, পর্যবেক্ষণ ছাড়াও, তারা কীভাবে সারিটি পুনরায় প্লে করা হয়েছিল তার উপর নিয়ন্ত্রণ চায় গতিশীলভাবে পরিবর্তন, পুনঃক্রম, বা এমনকি পৃথক অনুরোধ বাতিল করার ক্ষমতা।
v4-এ, এই কলব্যাকগুলিকে একটি একক onSync কলব্যাকের অনুকূলে সরিয়ে দেওয়া হয়েছে, যেটি ব্রাউজার দ্বারা রিপ্লে করার চেষ্টা করা হলে যে কোনো সময় আহ্বান করা হয়। ডিফল্টরূপে onSync কলব্যাকটি replayRequests() চালু করবে, কিন্তু যদি রিপ্লে প্রক্রিয়ার উপর আপনার আরও নিয়ন্ত্রণের প্রয়োজন হয়, আপনি আপনার পছন্দ মতো সারিটি পুনরায় প্লে করতে উপরে তালিকাভুক্ত অ্যারে-এর মতো পদ্ধতিগুলি ব্যবহার করতে পারেন।
এখানে কাস্টম রিপ্লে লজিকের একটি উদাহরণ:
const queue = new workbox.backgroundSync.Queue('my-queue-name', {
onSync: async ({queue}) => {
let entry;
while ((entry = await this.shiftRequest())) {
try {
await fetch(entry.request);
} catch (error) {
console.error('Replay failed for request', entry.request, error);
await this.unshiftRequest(entry);
return;
}
}
console.log('Replay complete!');
},
});
একইভাবে, workbox.backgroundSync.Plugin ক্লাস Queue ক্লাসের মতো একই আর্গুমেন্ট গ্রহণ করে (যেহেতু এটি অভ্যন্তরীণভাবে একটি Queue ইন্সট্যান্স তৈরি করে), তাই এটি একইভাবে পরিবর্তিত হয়েছে।
ওয়ার্কবক্স- মেয়াদোত্তীর্ণ
npm প্যাকেজটির নাম পরিবর্তন করা হয়েছে workbox-expiration , অন্যান্য মডিউলের জন্য ব্যবহৃত নামকরণ পদ্ধতির সাথে মিলে যায়। এই প্যাকেজটি কার্যত পুরানো workbox-cache-expiration প্যাকেজের সমতুল্য, যা এখন অবচয়।
ওয়ার্কবক্স-সম্প্রচার-আপডেট
npm প্যাকেজটির নাম পরিবর্তন করা হয়েছে workbox-broadcast-update , অন্যান্য মডিউলের জন্য ব্যবহৃত নামকরণ পদ্ধতির সাথে মিলে যায়। এই প্যাকেজটি কার্যত পুরানো workbox-broadcast-cache-update প্যাকেজের সমতুল্য, যা এখন অবমূল্যায়িত।
ওয়ার্কবক্স-কোর
Workbox v3-এ লগ লেভেলের ভার্বোসিটি workbox.core.setLogLevel() পদ্ধতির মাধ্যমে নিয়ন্ত্রিত করা যেতে পারে, যেটি আপনি workbox.core.LOG_LEVELS enum-এর একটি মান পাস করবেন। আপনি workbox.core.logLevel এর মাধ্যমে বর্তমান লগ স্তরটিও পড়তে পারেন।
ওয়ার্কবক্স v4-এ, সমস্ত আধুনিক বিকাশকারী সরঞ্জামগুলি এখন সমৃদ্ধ লগ ফিল্টারিং ক্ষমতা সহ পাঠানোর কারণে এগুলিকে সরিয়ে দেওয়া হয়েছে (Chrome Dev Tools-এর জন্য কনসোল আউটপুট ফিল্টারিং দেখুন)৷
workbox-sw
দুটি পদ্ধতি যা আগে সরাসরি workbox নেমস্পেসে প্রকাশ করা হয়েছিল (যা workbox-sw মডিউলের সাথে মিলে যায়) পরিবর্তে workbox.core এ সরানো হয়েছে। workbox.skipWaiting() হয়েছে workbox.core.skipWaiting() এবং একইভাবে, workbox.clientsClaim() হয়েছে workbox.core.clientsClaim() ।
টুল কনফিগারেশন তৈরি করুন
ওয়ার্কবক্স-ক্লি, ওয়ার্কবক্স-বিল্ড, বা ওয়ার্কবক্স-ওয়েবপ্যাক-প্লাগইনে পাস করা যেতে পারে এমন কিছু বিকল্পের নামকরণ পরিবর্তিত হয়েছে। যখনই "Url" একটি বিকল্পের নামে ব্যবহার করা হয়েছে, তখনই এটি "URL" এর পক্ষে অবমূল্যায়িত হয়েছে। এর মানে হল যে নিম্নলিখিত বিকল্প নাম পছন্দ করা হয়:
-
dontCacheBustURLsMatching -
ignoreURLParametersMatching -
modifyURLPrefix -
templatedURLs
এই বিকল্প নামের "Url" বৈচিত্রটি এখনও v4 তে কাজ করে, কিন্তু এর ফলে একটি সতর্কতা বার্তা আসবে। আমরা ডেভেলপারদেরকে v5 রিলিজের আগেই মাইগ্রেট করতে উৎসাহিত করি।
নতুন কার্যকারিতা
ওয়ার্কবক্স-উইন্ডো
নতুন workbox-window মডিউল পরিষেবা কর্মী নিবন্ধন এবং আপডেট সনাক্তকরণের প্রক্রিয়াকে সহজ করে, এবং পরিষেবা কর্মীতে চলমান কোড এবং আপনার ওয়েব অ্যাপের window প্রেক্ষাপটে চলমান কোডের মধ্যে যোগাযোগের একটি আদর্শ মাধ্যম প্রদান করে৷
workbox-window ব্যবহার করা ঐচ্ছিক হলেও, আমরা আশা করি যে ডেভেলপাররা এটিকে উপযোগী মনে করবেন এবং উপযুক্ত হলে এটি ব্যবহার করার জন্য তাদের হাতে লেখা কিছু যুক্তি স্থানান্তর করার কথা বিবেচনা করুন। আপনি মডিউলের গাইডে workbox-window ব্যবহার সম্পর্কে আরও জানতে পারেন।
উদাহরণ মাইগ্রেশন
ওয়ার্কবক্স v3 থেকে v4 এ বাস্তব-বিশ্ব স্থানান্তরের একটি উদাহরণ এই পুল অনুরোধে পাওয়া যাবে।
সাহায্য পাচ্ছেন
আমরা অনুমান করি যে বেশিরভাগ মাইগ্রেশন সোজা হবে। আপনি যদি এই নির্দেশিকায় কভার না করা সমস্যার সম্মুখীন হন, তাহলে অনুগ্রহ করে GitHub-এ একটি সমস্যা খোলার মাধ্যমে আমাদের জানান।