Workbox v4 থেকে v5 এ স্থানান্তর করুন, Workbox v4 থেকে v5 এ স্থানান্তর করুন

ওয়ার্কবক্স v4 থেকে আপগ্রেড করার সময় আপনাকে কী পরিবর্তন করতে হবে তার উদাহরণ সহ এই নির্দেশিকাটি ওয়ার্কবক্স v5-এ প্রবর্তিত পরিবর্তনগুলি ভাঙার উপর দৃষ্টি নিবদ্ধ করে।

ব্রেকিং পরিবর্তন

প্লাগইন ক্লাসের নাম পরিবর্তন করা হয়েছে

ওয়ার্কবক্স v4 প্যাকেজের একটি সংখ্যক Plugin নামের ক্লাস অন্তর্ভুক্ত করে। v5 এ, প্যাটার্ন প্যাকেজ শনাক্তকারী + Plugin অনুসরণ করার জন্য সেই ক্লাসগুলির নাম পরিবর্তন করা হয়েছে:

  • BackgroundSyncPlugin
  • BroadcastUpdatePlugin
  • CacheableResponsePlugin
  • ExpirationPlugin
  • RangeRequestsPlugin

আপনি মডিউল আমদানির মাধ্যমে বা workbox.* নামস্থান।

ডিফল্ট Precache ম্যানিফেস্ট প্রতিস্থাপন পয়েন্ট

পূর্বে, "ইনজেক্ট ম্যানিফেস্ট" মোডে বিল্ড টুলগুলির একটি ব্যবহার করার সময়, আপনার সোর্স সার্ভিস ওয়ার্কার ফাইলটি precacheAndRoute([]) এর উপস্থিতির জন্য চেক করা হয়েছিল, সেই খালি অ্যারে [] যে বিন্দুতে precache হয় তার জন্য একটি স্থানধারক হিসাবে ব্যবহৃত হয়েছিল। ম্যানিফেস্ট ইনজেকশন ছিল.

Workbox v5-এ, প্রতিস্থাপনের যুক্তি পরিবর্তিত হয়েছে, এবং এখন self.__WB_MANIFEST ডিফল্টরূপে ইনজেকশন পয়েন্ট হিসাবে ব্যবহৃত হয়।

// v4:
precacheAndRoute([]);

// v5:
precacheAndRoute(self.__WB_MANIFEST);

এই আলোচনায় বর্ণিত হিসাবে, আমরা বিশ্বাস করি যে এই পরিবর্তনটি একটি সহজ অভিজ্ঞতা প্রদান করে, একই সাথে বিকাশকারীদের কাস্টম পরিষেবা কর্মী কোডের মধ্যে কীভাবে ইনজেকশন করা ম্যানিফেস্ট ব্যবহার করা হয় তার উপর আরও নিয়ন্ত্রণ দেয়৷ প্রয়োজন হলে, আপনি injectionPoint কনফিগারেশন বিকল্পের মাধ্যমে এই প্রতিস্থাপন স্ট্রিং পরিবর্তন করতে পারেন।

দুটি বিকল্প যা আগে নেভিগেশন রুটের জন্য সমর্থিত ছিল, blacklist এবং whitelist নাম পরিবর্তন করা হয়েছে denylist এবং allowlist

workbox-routing পূর্বে একটি পদ্ধতি সমর্থন করেছিল, registerNavigationRoute() , যেটি, হুডের নীচে, দুটি জিনিস করেছিল:

  1. একটি প্রদত্ত fetch ইভেন্টে 'navigate' একটি mode আছে কিনা তা শনাক্ত করা হয়েছে।
  2. যদি তাই হয়, তবে সেই অনুরোধে সাড়া দেওয়া হয়েছে পূর্বে ক্যাশ করা, হার্ডকোড করা URL-এর বিষয়বস্তু ব্যবহার করে, URL যা-ই নেভিগেট করা হোক না কেন।

অ্যাপ শেল আর্কিটেকচার প্রয়োগ করার সময় এটি ব্যবহার করার জন্য একটি সাধারণ প্যাটার্ন।

দ্বিতীয় ধাপ, ক্যাশে থেকে পড়ার মাধ্যমে একটি প্রতিক্রিয়া তৈরি করা, আমরা workbox-routing এর দায়িত্ব হিসাবে যা দেখি তার বাইরে পড়ে। পরিবর্তে, আমরা এটিকে কার্যকারিতা হিসাবে দেখি যা workbox-precaching অংশ হওয়া উচিত, একটি নতুন পদ্ধতির মাধ্যমে, createHandlerBoundToURL() । এই নতুন পদ্ধতিটি একই যুক্তি সম্পন্ন করার জন্য workbox-routing এ বিদ্যমান NavigationRoute ক্লাসের সাথে হাতে হাত মিলিয়ে কাজ করতে পারে।

আপনি যদি বিল্ড টুলের "জেনারেট এসডব্লিউ" মোডে navigateFallback বিকল্পটি ব্যবহার করেন, তাহলে সুইচওভারটি স্বয়ংক্রিয়ভাবে ঘটবে। আপনি যদি আগে হয় navigateFallbackBlacklist বা navigateFallbackWhitelist বিকল্পগুলি কনফিগার করে থাকেন, সেগুলিকে যথাক্রমে নেভিগেট navigateFallbackDenylist বা navigateFallbackAllowlist এ পরিবর্তন করুন৷

আপনি যদি "ইনজেক্ট ম্যানিফেস্ট" মোড ব্যবহার করেন বা শুধুমাত্র পরিষেবা কর্মী নিজেই লিখে থাকেন, এবং আপনার Workbox v4 পরিষেবা কর্মী সরাসরি registerNavigationRoute() কল করেন, তাহলে সমতুল্য আচরণ পেতে আপনাকে আপনার কোডে একটি পরিবর্তন করতে হবে৷

// v4:
import {getCacheKeyForURL} from 'workbox-precaching';
import {registerNavigationRoute} from 'workbox-routing';

const appShellCacheKey = getCacheKeyForURL('/app-shell.html');
registerNavigationRoute(appShellCacheKey, {
  whitelist: [...],
  blacklist: [...],
});

// v5:
import {createHandlerBoundToURL} from 'workbox-precaching';
import {NavigationRoute, registerRoute} from 'workbox-routing';

const handler = createHandlerBoundToURL('/app-shell.html');
const navigationRoute = new NavigationRoute(handler, {
  allowlist: [...],
  denylist: [...],
});
registerRoute(navigationRoute);

আপনাকে আর getCacheKeyForURL() কল করতে হবে না, কারণ createHandlerBoundToURL() আপনার জন্য এটির যত্ন নেবে৷

ওয়ার্কবক্স-কৌশল থেকে makeRequest() অপসারণ

makeRequest() কল করা বেশিরভাগ workbox-strategy ক্লাসে কলিং handle() এর সমতুল্য। দুটি পদ্ধতির মধ্যে পার্থক্য এতটাই সামান্য ছিল যে উভয়কে ঘিরে রাখার অর্থ ছিল না। বিকাশকারীরা যারা makeRequest() কল করেছে তারা আর কোন পরিবর্তন ছাড়াই handle() ব্যবহারে স্যুইচ করতে সক্ষম হবে:

// v4:
const strategy = new StaleWhileRevalidate({...});
const response = await strategy.makeRequest({event, request});

// v5:
const strategy = new StaleWhileRevalidate({...});
const response = await strategy.handle({event, request});

v5-এ, handle() request একটি প্রয়োজনীয় প্যারামিটার হিসাবে বিবেচনা করে এবং event.request ব্যবহার করে ফিরে আসবে না। handle() কল করার সময় আপনি একটি বৈধ অনুরোধ পাস করেছেন তা নিশ্চিত করুন।

workbox-broadcast-update সর্বদা postMessage() ব্যবহার করে

v4-এ, workbox-broadcast-update লাইব্রেরিটি বার্তা পাঠানোর জন্য ব্রডকাস্ট চ্যানেল API ব্যবহার করার জন্য ডিফল্ট হবে যখন এটি সমর্থিত ছিল, এবং postMessage() ব্যবহারে ফিরে আসবে যখন ব্রডকাস্ট চ্যানেল সমর্থিত ছিল না।

আমরা বুঝতে পেরেছি যে ইনকামিং বার্তাগুলির দুটি সম্ভাব্য উত্সের জন্য শোনার ফলে ক্লায়েন্ট-সাইড কোড লেখার কাজটি অত্যধিক জটিল হয়ে উঠেছে। অতিরিক্তভাবে, কিছু ব্রাউজারে, ক্লায়েন্ট পৃষ্ঠাগুলিতে পাঠানো পরিষেবা কর্মী থেকে postMessage() কলগুলি স্বয়ংক্রিয়ভাবে বাফার হয়ে যায় যতক্ষণ না একটি message ইভেন্ট লিসেনার সেট আপ করা হয়। ব্রডকাস্ট চ্যানেল API এর সাথে কোন বাফারিং নেই, এবং সম্প্রচারিত বার্তাগুলি ড্রপ করা হয় যদি একটি ক্লায়েন্ট পৃষ্ঠা তাদের গ্রহণের জন্য প্রস্তুত হওয়ার আগে পাঠানো হয়।

এই কারণে, আমরা সবসময় v5 এ postMessage() ব্যবহার করার জন্য workbox-broadcast-update পরিবর্তন করেছি। বর্তমান পরিষেবা কর্মীর সুযোগের মধ্যে সমস্ত ক্লায়েন্ট পৃষ্ঠাগুলিতে বার্তাগুলি একের পর এক পাঠানো হয়।

এই নতুন আচরণকে সামঞ্জস্য করার জন্য, আপনি BroadcastChannel দৃষ্টান্ত তৈরি করা ক্লায়েন্ট পৃষ্ঠাগুলিতে থাকা যেকোন কোডটি সরাতে পারেন এবং পরিবর্তে, navigator.serviceWorker এ একটি message ইভেন্ট লিসেনার সেট আপ করতে পারেন:

// v4:
const updatesChannel = new BroadcastChannel('api-updates');
updatesChannel.addEventListener('message', event => {
  const {cacheName, updatedUrl} = event.data.payload;
  // ... your code here ...
});

// v5:
// This listener should be added as early as possible in your page's lifespan
// to ensure that messages are properly buffered.
navigator.serviceWorker.addEventListener('message', event => {
  // Optional: ensure the message came from workbox-broadcast-update
  if (event.meta === 'workbox-broadcast-update') {
    const {cacheName, updatedUrl} = event.data.payload;
    // ... your code here ...
  }
});

workbox-window ব্যবহারকারীদের কোনো পরিবর্তন করতে হবে না, কারণ postMessage() কল শোনার জন্য এর অভ্যন্তরীণ যুক্তি আপডেট করা হয়েছে।

বিল্ড টুলের জন্য Node.js v8 বা উচ্চতর প্রয়োজন

v8-এর আগের Node.js সংস্করণগুলি আর workbox-webpack-plugin , workbox-build বা workbox-cli এর জন্য সমর্থিত নয়। আপনি যদি 8-এর আগে একটি Node.js সংস্করণ চালান, তাহলে আপনার রানটাইম একটি সমর্থিত সংস্করণে আপডেট করুন।

workbox-webpack-plugin এর জন্য ওয়েবপ্যাক v4 বা উচ্চতর প্রয়োজন

আপনি যদি workbox-webpack-plugin ব্যবহার করেন তবে অন্তত ওয়েবপ্যাক v4 ব্যবহার করতে আপনার ওয়েবপ্যাক সেটআপ আপডেট করুন

বিল্ড টুল অপশন ওভারহল

workbox-build , workbox-cli , এবং workbox-webpack-plugin কনফিগারেশন প্যারামিটার আর সমর্থিত নয়। উদাহরণস্বরূপ, generateSW সর্বদা আপনার জন্য একটি স্থানীয় ওয়ার্কবক্স রানটাইম বান্ডিল তৈরি করবে, তাই importWorkboxFrom বিকল্পটি আর অর্থবহ নয়।

সমর্থিত বিকল্পগুলির তালিকার জন্য প্রাসঙ্গিক টুলের ডকুমেন্টেশনের সাথে পরামর্শ করুন।

ওয়ার্কবক্স-বিল্ড থেকে generateSWString অপসারণ

generateSWString মোড workbox-build থেকে সরানো হয়েছে। আমরা আশা করি এর প্রভাব ন্যূনতম হবে, কারণ এটি প্রাথমিকভাবে workbox-webpack-plugin দ্বারা অভ্যন্তরীণভাবে ব্যবহৃত হয়েছিল।

ঐচ্ছিক পরিবর্তন

মডিউল আমদানি ব্যবহার করে

যদিও এই পরিবর্তনটি a) ঐচ্ছিক এবং b) প্রযুক্তিগতভাবে ওয়ার্কবক্স v4 ব্যবহার করার সময় সম্ভব হয়েছিল, v5 এ যাওয়ার সময় আমরা যে সবচেয়ে বড় পরিবর্তনটি আশা করি তা হল একটি মডেল যেখানে আপনি ওয়ার্কবক্সের মডিউলগুলি আমদানি করে আপনার নিজস্ব বান্ডিল পরিষেবা কর্মী তৈরি করেন৷ এই পদ্ধতিটি আপনার পরিষেবা কর্মীর শীর্ষে importScripts('/path/to/workbox-sw.js') কল করার এবং workbox.* নামস্থান।

আপনি যদি "জেনারেট SW" মোডে বিল্ড টুল ( workbox-webpack-plugin , workbox-build , workbox-cli ) ব্যবহার করছেন, তাহলে এই পরিবর্তনটি আপনার জন্য স্বয়ংক্রিয়ভাবে ঘটবে৷ এই সমস্ত সরঞ্জামগুলি আপনার পরিষেবা কর্মী যুক্তি বাস্তবায়নের জন্য প্রয়োজনীয় প্রকৃত কোডের পাশাপাশি ওয়ার্কবক্স রানটাইমের একটি স্থানীয়, কাস্টম বান্ডিল আউটপুট করবে। এই পরিস্থিতিতে, workbox-sw বা ওয়ার্কবক্সের CDN কপির উপর আর কোনো নির্ভরতা নেই। আপনার inlineWorkboxRuntime কনফিগারেশনের মানের উপর নির্ভর করে, ওয়ার্কবক্স রানটাইম হয় একটি পৃথক ফাইলে বিভক্ত হবে যা আপনার পরিষেবা কর্মী (যখন false সেট করা হয়, যা ডিফল্ট) এর সাথে স্থাপন করা উচিত, অথবা পরিষেবা কর্মী লজিকের সাথে ইনলাইন অন্তর্ভুক্ত করা হবে ( যখন true সেট করা হয়)।

আপনি যদি "ইনজেক্ট ম্যানিফেস্ট" মোডে বিল্ড টুল ব্যবহার করে থাকেন, অথবা আপনি যদি ওয়ার্কবক্সের বিল্ড টুলগুলি একেবারেই ব্যবহার না করে থাকেন, তাহলে আপনি বিদ্যমান বান্ডলার (ওয়েবপ্যাক/রোলআপ) ব্যবহার করে আপনার নিজস্ব ওয়ার্কবক্স রানটাইম বান্ডেল তৈরি সম্পর্কে আরও জানতে পারবেন ওয়ার্কবক্স গাইড।

v5 এর জন্য ডকুমেন্টেশন এবং উদাহরণগুলি মডিউল ইম্পোর্ট সিনট্যাক্স ধরে নিয়ে লেখা হয়েছে, যদিও workbox.* নামস্থান ওয়ার্কবক্স v5-এ সমর্থিত থাকবে।

প্রিক্যাচড রেসপন্স পড়া

কিছু ডেভেলপারদের precacheAndRoute() পদ্ধতির মাধ্যমে অস্পষ্টভাবে ব্যবহার করার পরিবর্তে সরাসরি ক্যাশে থেকে প্রিক্যাচ করা প্রতিক্রিয়া পড়তে হবে। v4-এ একটি সাধারণ প্যাটার্ন হল প্রথমে একটি প্রিক্যাচেড রিসোর্সের বর্তমান সংস্করণের জন্য নির্দিষ্ট ক্যাশে কী পেতে হবে এবং তারপরে Response পেতে caches.match() এ precache-এর ক্যাশে নামের সাথে সেই কীটি পাস করুন।

এই প্রক্রিয়াটিকে সহজ করার জন্য, v5-এ workbox-precaching একটি নতুন, সমতুল্য পদ্ধতি, matchPrecache() সমর্থন করে :

// v4:
import {cacheNames} from 'workbox-core';
import {getCacheKeyForURL} from 'workbox-precaching';

const cachedResponse = await caches.match(
  getCacheKeyForURL(`/somethingPrecached`),
  {
    cacheName: cacheNames.precache,
  }
);

// v5:
import {matchPrecache} from 'workbox-precaching';

const cachedResponse = await matchPrecache(`/somethingPrecached`);

টাইপস্ক্রিপ্ট গ্রহণ

v5-এ, ওয়ার্কবক্স রানটাইম লাইব্রেরিগুলি টাইপস্ক্রিপ্টে লেখা হয়। যদিও আমরা টাইপস্ক্রিপ্ট গ্রহণ করেনি এমন ডেভেলপারদের জন্য স্থানান্তরিত জাভাস্ক্রিপ্ট মডিউল এবং বান্ডেল প্রকাশ করা চালিয়ে যাব, আপনি যদি টাইপস্ক্রিপ্ট ব্যবহার করেন, তাহলে ওয়ার্কবক্স প্রকল্প থেকে সরাসরি সঠিক, সর্বদা আপ-টু-ডেট টাইপ তথ্য থেকে আপনার উপকৃত হওয়া উচিত।

উদাহরণ মাইগ্রেশন

এই কমিট ইনলাইন ভাষ্য সহ একটি মোটামুটি জড়িত মাইগ্রেশন চিত্রিত করে। এটি CDN থেকে রানটাইম লোড করার পরিবর্তে চূড়ান্ত পরিষেবা কর্মীতে একটি কাস্টম ওয়ার্কবক্স রানটাইম অন্তর্ভুক্ত করতে রোলআপ ব্যবহার করে।

যদিও এটি প্রতিটি ব্রেকিং পরিবর্তনকে কভার করে না, এখানে একটি পরিষেবা কর্মী ফাইল v4 থেকে v5 তে আপগ্রেড করার আগে এবং পরে , টাইপস্ক্রিপ্টে একটি স্যুইচ সহ।

সাহায্য পাচ্ছি

আমরা অনুমান করি যে বেশিরভাগ মাইগ্রেশন সোজা হবে। আপনি যদি এই নির্দেশিকায় কভার না করা সমস্যার সম্মুখীন হন, GitHub-এ একটি সমস্যা খোলার মাধ্যমে আমাদের জানান।