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

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

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

ওয়ার্কবক্স-কোর

workbox-core -এ skipWaiting() পদ্ধতিটি আর একটি install হ্যান্ডলারে যুক্ত হবে না এবং এটি শুধুমাত্র self.skipWaiting() কল করার সমতুল্য।

এখন থেকে, এর পরিবর্তে self.skipWaiting() ব্যবহার করুন যেহেতু skipWaiting() সম্ভবত Workbox v7 থেকে সরানো হবে।

ওয়ার্কবক্স-প্রেক্যাচিং

• একটি HTTP পুনঃনির্দেশের সাথে সঙ্গতিপূর্ণ URLগুলির জন্য ক্রস-অরিজিন HTML ডকুমেন্টগুলিকে workbox-precaching সাথে একটি নেভিগেশন অনুরোধ সন্তুষ্ট করতে আর ব্যবহার করা যাবে না। এই দৃশ্যটি সাধারণত অস্বাভাবিক।
• fbclid URL ক্যোয়ারী প্যারামিটার এখন workbox-precaching দ্বারা উপেক্ষা করা হয় যখন একটি প্রদত্ত অনুরোধের জন্য একটি প্রিক্যাচড প্রতিক্রিয়া খুঁজছেন।
• PrecacheController কনস্ট্রাক্টর এখন একটি স্ট্রিংয়ের পরিবর্তে নির্দিষ্ট বৈশিষ্ট্য সহ একটি বস্তুকে এর প্যারামিটার হিসাবে গ্রহণ করে। এই অবজেক্টটি নিম্নলিখিত বৈশিষ্ট্যগুলিকে সমর্থন করে: cacheName (v5-এ কনস্ট্রাক্টরকে পাস করা স্ট্রিংয়ের মতো একই উদ্দেশ্য পরিবেশন করা), plugins (v5 থেকে addPlugins() পদ্ধতিটি প্রতিস্থাপন করা), এবং fallbackToNetwork (অনুরূপ বিকল্পটি প্রতিস্থাপন করা যা পাস করা হয়েছিল createHandler() এবং `createHandlerBoundToURL() v5 তে।
• PrecacheController এর install() এবং activate() পদ্ধতিগুলি এখন ঠিক একটি প্যারামিটার নেয়, যা যথাক্রমে একটি সংশ্লিষ্ট InstallEvent বা ActivateEvent এ সেট করা উচিত।
• addRoute() পদ্ধতি PrecacheController থেকে সরানো হয়েছে। এর জায়গায়, নতুন PrecacheRoute ক্লাস একটি রুট তৈরি করতে ব্যবহার করা যেতে পারে যা আপনি তারপর নিবন্ধন করতে পারেন।
• precacheAndRoute() পদ্ধতি PrecacheController থেকে সরানো হয়েছে। (এটি এখনও workbox-precaching মডিউল দ্বারা রপ্তানি করা একটি স্ট্যাটিক সহায়ক পদ্ধতি হিসাবে বিদ্যমান।) এটি সরানো হয়েছে কারণ এর পরিবর্তে PrecacheRoute ব্যবহার করা যেতে পারে।
• createMatchCalback() পদ্ধতিটি PrecacheController থেকে সরানো হয়েছে। এর পরিবর্তে নতুন PrecacheRoute ব্যবহার করা যেতে পারে।
• createHandler() পদ্ধতি PrecacheController থেকে সরানো হয়েছে। পরিবর্তে অনুরোধগুলি পরিচালনা করতে PrecacheController অবজেক্টের strategy বৈশিষ্ট্য ব্যবহার করা যেতে পারে।
• createHandler() স্ট্যাটিক এক্সপোর্ট ইতিমধ্যে workbox-precaching মডিউল থেকে সরানো হয়েছে। এর জায়গায়, বিকাশকারীদের একটি PrecacheController উদাহরণ তৈরি করা উচিত এবং এর strategy সম্পত্তি ব্যবহার করা উচিত।
• precacheAndRoute() এর সাথে নিবন্ধিত রুটটি এখন একটি "বাস্তব" রুট যা হুডের নিচে workbox-routing এর Router ক্লাস ব্যবহার করে। আপনি registerRoute() এবং precacheAndRoute() এ কল ইন্টারলেভ করলে এটি আপনার রুটের একটি ভিন্ন মূল্যায়নের ক্রম তৈরি করতে পারে।

ওয়ার্কবক্স-রাউটিং

setDefaultHandler() পদ্ধতিটি এখন HTTP পদ্ধতির সাথে সম্পর্কিত একটি ঐচ্ছিক দ্বিতীয় প্যারামিটার নেয় যা এটি প্রযোজ্য, ডিফল্ট করে 'GET' ।

• আপনি যদি setDefaultHandler() ব্যবহার করেন এবং আপনার সমস্ত অনুরোধ GET হয়, তাহলে কোনো পরিবর্তন করতে হবে না।
• আপনার যদি এমন কোনো অনুরোধ থাকে যা GET ( POST , PUT , etc...) না হয়, setDefaultHandler() সেই অনুরোধগুলিকে আর মিলবে না।

কনফিগারেশন তৈরি করুন

workbox-build এবং workbox-cli এ getManifest এবং injectManifest মোডগুলির জন্য mode বিকল্পটি সমর্থন করার উদ্দেশ্যে ছিল না এবং সরিয়ে দেওয়া হয়েছে। এটি workbox-webpack-plugin ক্ষেত্রে প্রযোজ্য নয়, যা এর InjectManifest প্লাগইনে সমর্থন mode করে।

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

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

নতুন উন্নতি

ওয়ার্কবক্স-কৌশল

Workbox v6 তৃতীয় পক্ষের বিকাশকারীদের তাদের নিজস্ব ওয়ার্কবক্স কৌশলগুলি সংজ্ঞায়িত করার জন্য একটি নতুন উপায় প্রবর্তন করে৷ এটি নিশ্চিত করে যে তৃতীয় পক্ষের বিকাশকারীদের তাদের চাহিদা সম্পূর্ণরূপে পূরণ করার উপায়ে ওয়ার্কবক্স প্রসারিত করার ক্ষমতা রয়েছে।

নতুন কৌশল বেস ক্লাস

v6-এ, সমস্ত ওয়ার্কবক্স কৌশল ক্লাসকে অবশ্যই নতুন Strategy বেস ক্লাস প্রসারিত করতে হবে। এটিকে সমর্থন করার জন্য সমস্ত অন্তর্নির্মিত কৌশলগুলি পুনরায় লেখা হয়েছে।

Strategy বেস ক্লাস দুটি প্রাথমিক জিনিসের জন্য দায়ী:

• প্লাগইন লাইফসাইকেল কলব্যাক আহ্বান করা সমস্ত কৌশল হ্যান্ডলারদের জন্য সাধারণ (যেমন যখন তারা শুরু, প্রতিক্রিয়া এবং শেষ)।
• একটি "হ্যান্ডলার" উদাহরণ তৈরি করা, যা প্রতিটি পৃথক অনুরোধের জন্য রাষ্ট্র পরিচালনা করতে পারে একটি কৌশল পরিচালনা করছে।

নতুন "হ্যান্ডলার" ক্লাস

আমাদের আগে অভ্যন্তরীণ মডিউল ছিল fetchWrapper এবং cacheWrapper কল, যেটি (তাদের নাম থেকে বোঝা যায়) বিভিন্ন ফেচ এবং ক্যাশে এপিআইগুলিকে তাদের জীবনচক্রে হুক দিয়ে মোড়ানো। এটি এমন একটি প্রক্রিয়া যা বর্তমানে প্লাগইনগুলিকে কাজ করার অনুমতি দেয়, কিন্তু এটি বিকাশকারীদের কাছে প্রকাশ পায় না।

নতুন "হ্যান্ডলার" ক্লাস, StrategyHandler , এই পদ্ধতিগুলিকে প্রকাশ করবে যাতে কাস্টম কৌশলগুলি fetch() বা cacheMatch() কল করতে পারে এবং কৌশল উদাহরণে স্বয়ংক্রিয়ভাবে যোগ করা কোনও প্লাগইন থাকতে পারে৷

এই শ্রেণীটি ডেভেলপারদের জন্য তাদের নিজস্ব কাস্টম, লাইফসাইকেল কলব্যাক যোগ করাও সম্ভব করবে যা তাদের কৌশলগুলির জন্য নির্দিষ্ট হতে পারে এবং তারা বিদ্যমান প্লাগইন ইন্টারফেসের সাথে "শুধু কাজ করবে"।

নতুন প্লাগইন জীবনচক্র অবস্থা

ওয়ার্কবক্স v5-এ, প্লাগইনগুলি স্টেটলেস। তার মানে যদি /index.html জন্য একটি অনুরোধ requestWillFetch এবং cachedResponseWillBeUsed উভয় কলব্যাককে ট্রিগার করে, তাহলে এই দুটি কলব্যাকের একে অপরের সাথে যোগাযোগ করার বা এমনকি জানারও কোনো উপায় নেই যে তারা একই অনুরোধ দ্বারা ট্রিগার হয়েছে।

v6-এ, সমস্ত প্লাগইন কলব্যাকও একটি নতুন state অবজেক্ট পাস করা হবে। এই স্টেট অবজেক্টটি এই বিশেষ প্লাগইন অবজেক্ট এবং এই বিশেষ কৌশল আহ্বানের জন্য অনন্য হবে (অর্থাৎ handle() )। এটি ডেভেলপারদের প্লাগইনগুলি লিখতে অনুমতি দেয় যেখানে একটি কলব্যাক শর্তসাপেক্ষে একই প্লাগইনের অন্য একটি কলব্যাকের উপর ভিত্তি করে কিছু করতে পারে (যেমন requestWillFetch এবং fetchDidSucceed বা fetchDidFail মধ্যে সময় ডেল্টা গণনা করুন)।

নতুন প্লাগইন লাইফসাইকেল কলব্যাক

নতুন প্লাগইন লাইফসাইকেল কলব্যাক যোগ করা হয়েছে যাতে ডেভেলপাররা প্লাগইন লাইফসাইকেল স্টেট সম্পূর্ণভাবে লাভ করতে পারে:

• handlerWillStart : যেকোনো হ্যান্ডলার লজিক চালু হওয়ার আগে কল করা হয়। এই কলব্যাকটি প্রাথমিক হ্যান্ডলার অবস্থা সেট করতে ব্যবহার করা যেতে পারে (যেমন শুরুর সময় রেকর্ড করুন)।
• handlerWillRespond : কৌশল handle() পদ্ধতি একটি প্রতিক্রিয়া প্রদান করার আগে বলা হয়। এই কলব্যাকটি একটি রুট হ্যান্ডলার বা অন্যান্য কাস্টম লজিকে ফেরত দেওয়ার আগে সেই প্রতিক্রিয়াটি সংশোধন করতে ব্যবহার করা যেতে পারে।
• handlerDidRespond : কৌশলের handle() পদ্ধতি একটি প্রতিক্রিয়া প্রদান করার পরে বলা হয়। এই কলব্যাকটি যেকোনো চূড়ান্ত প্রতিক্রিয়ার বিবরণ রেকর্ড করতে ব্যবহার করা যেতে পারে, যেমন অন্যান্য প্লাগইন দ্বারা করা পরিবর্তনের পরে।
• handlerDidComplete : এই কৌশলটির আহ্বান থেকে ইভেন্টে যোগ করা সমস্ত আজীবন প্রতিশ্রুতি নিষ্পত্তি হওয়ার পরে বলা হয়। এই কলব্যাকটি যে কোনও ডেটার রিপোর্ট করতে ব্যবহার করা যেতে পারে যা হ্যান্ডলারকে গণনা করার জন্য অপেক্ষা করতে হবে (যেমন ক্যাশে হিট স্ট্যাটাস, ক্যাশে লেটেন্সি, নেটওয়ার্ক লেটেন্সি)।
• handlerDidError : বলা হয় যদি হ্যান্ডলার কোনো উৎস থেকে একটি বৈধ প্রতিক্রিয়া প্রদান করতে অক্ষম হয়। এই কলব্যাকটি নেটওয়ার্ক ত্রুটির বিকল্প হিসাবে "ফলব্যাক" সামগ্রী সরবরাহ করতে ব্যবহার করা যেতে পারে।

বিকাশকারীরা তাদের নিজস্ব কাস্টম কৌশলগুলি বাস্তবায়ন করে এই কলব্যাকগুলিকে নিজেরাই নেওয়ার বিষয়ে চিন্তা করতে হবে না; যে সব একটি নতুন Strategy বেস ক্লাস দ্বারা পরিচালিত হয়.

হ্যান্ডলারদের জন্য আরো সঠিক TypeScript প্রকার

বিভিন্ন কলব্যাক পদ্ধতির জন্য TypeScript সংজ্ঞা স্বাভাবিক করা হয়েছে। এটি বিকাশকারীদের জন্য একটি ভাল অভিজ্ঞতার দিকে পরিচালিত করবে যারা TypeScript ব্যবহার করে এবং হ্যান্ডলারদের বাস্তবায়ন বা কল করার জন্য তাদের নিজস্ব কোড লেখে।

ওয়ার্কবক্স-উইন্ডো

নতুন বার্তা SkipWaiting() পদ্ধতি

একটি নতুন পদ্ধতি, messageSkipWaiting() , workbox-window মডিউলে যোগ করা হয়েছে যাতে "অপেক্ষারত" পরিষেবা কর্মীকে সক্রিয় করতে বলার প্রক্রিয়া সহজতর হয়। এটি কিছু উন্নতি প্রস্তাব করে:

• এটি postMessage() কে ডি ফ্যাক্টো স্ট্যান্ডার্ড মেসেজ বডি, {type: 'SKIP_WAITING'} দিয়ে কল করে, যেটি ওয়ার্কবক্স দ্বারা তৈরি করা একজন পরিষেবা কর্মী skipWaiting() ট্রিগার করার জন্য চেক করে।
• এই বার্তাটি পোস্ট করার জন্য এটি সঠিক "অপেক্ষারত" পরিষেবা কর্মী বেছে নেয়, এমনকি যদি এটি একই পরিষেবা কর্মী না হয় যার সাথে workbox-window নিবন্ধিত ছিল৷

একটি isExternal সম্পত্তির পক্ষে "বাহ্যিক" ইভেন্টগুলি সরানো৷

workbox-window থাকা সমস্ত "বহিরাগত" ইভেন্টগুলিকে "স্বাভাবিক" ইভেন্টের জায়গায় সরানো হয়েছে একটি isExternal সম্পত্তি true সেট করা হয়েছে। এটি বিকাশকারীদের যারা পার্থক্য সম্পর্কে যত্নশীল তাদের এখনও এটি সনাক্ত করতে অনুমতি দেয় এবং যাদের জানার প্রয়োজন নেই তারা সম্পত্তিটিকে উপেক্ষা করতে পারে।

ক্লিনার "ব্যবহারকারীদের জন্য একটি পৃষ্ঠা পুনরায় লোড করার প্রস্তাব" রেসিপি

উপরের উভয় পরিবর্তনের জন্য ধন্যবাদ, "ব্যবহারকারীদের জন্য একটি পৃষ্ঠা পুনরায় লোড করার প্রস্তাব করুন" রেসিপিটি সরলীকৃত করা যেতে পারে:

MULTI_LINE_CODE_PLACEHOLDER_0

ওয়ার্কবক্স-রাউটিং

একটি নতুন বুলিয়ান প্যারামিটার, sameOrigin , workbox-routing ব্যবহৃত matchCallback ফাংশনে পাস করা হয়। অনুরোধটি একই-উৎস URL-এর জন্য হলে এটি true এবং অন্যথায় মিথ্যা হিসাবে সেট করা হয়।

এটি কিছু সাধারণ বয়লারপ্লেটকে সরল করে:

MULTI_LINE_CODE_PLACEHOLDER_1

ওয়ার্কবক্সে matchOptions- মেয়াদ শেষ

আপনি এখন workbox-expiration এ matchOptions সেট করতে পারেন, যা পরে অন্তর্নিহিত cache.delete() কলে CacheQueryOptions হিসাবে পাস করা হবে। (বেশিরভাগ বিকাশকারীদের এটি করতে হবে না।)

ওয়ার্কবক্স-প্রেক্যাচিং

ওয়ার্কবক্স-কৌশল ব্যবহার করে

workbox-precaching একটি ভিত্তি হিসাবে workbox-strategies ব্যবহার করার জন্য পুনরায় লেখা হয়েছে। এর ফলে কোনো ব্রেকিং পরিবর্তন হওয়া উচিত নয়, এবং দুটি মডিউল কীভাবে নেটওয়ার্ক এবং ক্যাশে অ্যাক্সেস করে তাতে দীর্ঘমেয়াদী ধারাবাহিকতা বজায় রাখা উচিত।

প্রিক্যাচিং এখন একের পর এক এন্ট্রি প্রক্রিয়া করে, বাল্ক নয়

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

এটি প্রিক্যাচিং করার সময় net::ERR_INSUFFICIENT_RESOURCES ত্রুটির সম্ভাবনা হ্রাস করবে এবং ওয়েব অ্যাপের দ্বারা করা প্রিক্যাচিং এবং একযোগে অনুরোধের মধ্যে ব্যান্ডউইথের বিরোধও হ্রাস করবে৷

PrecacheFallbackPlugin সহজ অফলাইন ফলব্যাকের জন্য অনুমতি দেয়

workbox-precaching এখন একটি PrecacheFallbackPlugin অন্তর্ভুক্ত রয়েছে, যা v6-এ যোগ করা নতুন handlerDidError লাইফসাইকেল পদ্ধতি প্রয়োগ করে।

এটি একটি প্রদত্ত কৌশলের জন্য একটি "ফলব্যাক" হিসাবে একটি পূর্বক্যাচেড ইউআরএল নির্দিষ্ট করা সহজ করে যখন একটি প্রতিক্রিয়া অন্যথায় উপলব্ধ হবে না। প্লাগইনটি প্রিক্যাচড ইউআরএল-এর জন্য সঠিক ক্যাশে কী তৈরি করার যত্ন নেবে, যেকোনও রিভিশন প্যারামিটার সহ প্রয়োজনীয়।

যখন NetworkOnly কৌশল একটি নেভিগেশন অনুরোধের জন্য একটি প্রতিক্রিয়া তৈরি করতে পারে না তখন একটি precached /offline.html সাথে প্রতিক্রিয়া জানাতে এটি ব্যবহার করার একটি নমুনা এখানে রয়েছে - অন্য কথায়, একটি কাস্টম অফলাইন HTML পৃষ্ঠা প্রদর্শন করা হচ্ছে:

MULTI_LINE_CODE_PLACEHOLDER_2

রানটাইম ক্যাশে precacheFallback

আপনি যদি আপনার পরিষেবা কর্মীকে হাতে লেখার পরিবর্তে আপনার জন্য একটি পরিষেবা কর্মী তৈরি করতে generateSW ব্যবহার করছেন, আপনি একই জিনিসটি সম্পাদন করতে runtimeCaching -এ নতুন precacheFallback কনফিগারেশন বিকল্পটি ব্যবহার করতে পারেন:

{
  // ... other generateSW config options...
  runtimeCaching: [{
    urlPattern: ({request}) => request.mode === 'navigate',
    handler: 'NetworkOnly',
    options: {
      precacheFallback: {
        // This URL needs to be included in your precache manifest.
        fallbackURL: '/offline.html',
      },
    },
  }],
}

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

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