ย้ายข้อมูลจาก Workbox v5 ไปยัง v6

คู่มือนี้เน้นการเปลี่ยนแปลงที่นำมาใช้ใน Workbox v6 พร้อมตัวอย่างการเปลี่ยนแปลงที่คุณจำเป็นต้องทำเมื่ออัปเกรดจาก Workbox v5

การเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ

แกนงาน

เมธอด skipWaiting() ใน workbox-core จะไม่เพิ่มในเครื่องจัดการ install อีกต่อไป และเทียบเท่ากับการเรียกใช้ self.skipWaiting() เท่านั้น

จากนี้ไป ให้ใช้ self.skipWaiting() แทน เนื่องจากอาจมีการนำ skipWaiting() ออกจาก Workbox v7 แล้ว

การแคชพื้นที่ทำงานล่วงหน้า

• เอกสาร HTML แบบข้ามต้นทางสำหรับ URL ที่สอดคล้องกับการเปลี่ยนเส้นทาง HTTP จะไม่สามารถใช้เพื่อตอบสนองคำขอการนำทางด้วย workbox-precaching ได้อีกต่อไป สถานการณ์นี้มักพบได้ไม่บ่อยนัก
• ตอนนี้ workbox-precaching จะไม่สนใจพารามิเตอร์การค้นหา URL fbclid เมื่อค้นหาการตอบกลับที่แคชไว้ล่วงหน้าสําหรับคําขอหนึ่งๆ
• ตอนนี้ตัวสร้าง PrecacheController จะนำออบเจ็กต์ที่มีพร็อพเพอร์ตี้เฉพาะเป็นพารามิเตอร์แทนสตริง ออบเจ็กต์นี้สนับสนุนพร็อพเพอร์ตี้ต่อไปนี้ cacheName (ทำหน้าที่เหมือนสตริงที่ส่งผ่านไปยังตัวสร้างใน v5), plugins (แทนที่เมธอด addPlugins() จาก v5) และ fallbackToNetwork (แทนที่ตัวเลือกที่คล้ายกันที่ส่งผ่านไปยัง createHandler() และ `createHandlerBoundToURL() ใน v5)
• ตอนนี้เมธอด install() และ activate() ของ PrecacheController จะมีพารามิเตอร์เพียง 1 รายการเท่านั้น ซึ่งควรตั้งค่าเป็น InstallEvent หรือ ActivateEvent ที่เกี่ยวข้องตามลำดับ
• นำเมธอด addRoute() ออกจาก PrecacheController แล้ว ซึ่งจากนี้ไปคุณสามารถใช้คลาส PrecacheRoute ใหม่เพื่อสร้างเส้นทางเพื่อให้ลงทะเบียนได้
• นำเมธอด precacheAndRoute() ออกจาก PrecacheController แล้ว (แต่ยังคงเป็นเมธอดตัวช่วยแบบคงที่ที่ส่งออกโดยโมดูล workbox-precaching) ระบบได้นำออกเนื่องจากใช้ PrecacheRoute แทนได้
• นำเมธอด createMatchCalback() ออกจาก PrecacheController แล้ว คุณใช้ PrecacheRoute ใหม่แทนได้
• นำเมธอด createHandler() ออกจาก PrecacheController แล้ว คุณใช้พร็อพเพอร์ตี้ strategy ของออบเจ็กต์ PrecacheController เพื่อจัดการคำขอแทนได้
• ลบการส่งออกแบบคงที่ createHandler() ออกจากโมดูล workbox-precaching แล้ว นักพัฒนาซอฟต์แวร์ควรสร้างอินสแตนซ์ PrecacheController และใช้พร็อพเพอร์ตี้ strategy ของอินสแตนซ์ดังกล่าวแทน
• ขณะนี้เส้นทางที่ลงทะเบียนกับ precacheAndRoute() เป็นเส้นทาง "จริง" ซึ่งใช้คลาส Router ของ workbox-routing ในขั้นสูง ซึ่งอาจส่งผลให้มีลำดับการประเมินเส้นทางที่ต่างออกไปหากคุณแทรกการโทรไปยัง registerRoute() และ precacheAndRoute()

การกำหนดเส้นทางกล่องงาน

ตอนนี้เมธอด setDefaultHandler() จะใช้พารามิเตอร์ที่ 2 (ไม่บังคับ) ที่สอดคล้องกับเมธอด HTTP ที่ใช้อยู่ โดยมีค่าเริ่มต้นเป็น 'GET'

• คุณไม่ต้องทำการเปลี่ยนแปลงใดๆ หากใช้ setDefaultHandler() และคำขอทั้งหมดเป็น GET
• หากคุณมีคำขอที่ไม่ใช่ GET (POST, PUT ฯลฯ) setDefaultHandler() จะไม่ทำให้คำขอเหล่านั้นจับคู่กันอีกต่อไป

การกำหนดค่าบิวด์

ระบบไม่รองรับตัวเลือก mode สำหรับโหมด getManifest และ injectManifest ใน workbox-build และ workbox-cli และถูกนำออกแล้ว นโยบายนี้ไม่มีผลกับ workbox-webpack-plugin ซึ่งรองรับ mode ในปลั๊กอิน InjectManifest

เครื่องมือสร้างต้องใช้ Node.js v10 ขึ้นไป

ระบบไม่รองรับ Node.js เวอร์ชันก่อน v10 สำหรับ workbox-webpack-plugin, workbox-build หรือ workbox-cli อีกต่อไป หากกำลังใช้ Node.js เวอร์ชันเก่ากว่า v8 ให้อัปเดตรันไทม์เป็นเวอร์ชันที่รองรับ

การปรับปรุงใหม่

กลยุทธ์กล่องงาน

Workbox v6 นำเสนอวิธีใหม่ในการกำหนดกลยุทธ์ Workbox ให้กับนักพัฒนาซอฟต์แวร์บุคคลที่สาม ซึ่งจะทำให้นักพัฒนาซอฟต์แวร์บุคคลที่สามขยาย Workbox ให้ตอบสนองความต้องการของตนได้

คลาสฐานกลยุทธ์ใหม่

ในเวอร์ชัน 6 คลาสกลยุทธ์ Workbox ทั้งหมดต้องขยายคลาสฐาน Strategy ใหม่ เราได้เขียนกลยุทธ์ในตัวใหม่ทั้งหมดเพื่อสนับสนุนเรื่องนี้

คลาสพื้นฐาน Strategy มี 2 สิ่งหลักๆ ดังนี้

• การเรียกใช้โค้ดเรียกกลับของวงจรปลั๊กอินที่พบได้ทั่วไปสําหรับเครื่องจัดการกลยุทธ์ทั้งหมด (เช่น เมื่อเริ่มต้น ตอบสนอง และสิ้นสุด)
• การสร้างอินสแตนซ์ "เครื่องจัดการ" ที่สามารถจัดการสถานะสำหรับคำขอแต่ละรายการที่กลยุทธ์กำลังจัดการอยู่

คลาส "เครื่องจัดการ" ใหม่

ก่อนหน้านี้เรามีโมดูลภายในชื่อ fetchWrapper และ cacheWrapper ซึ่ง (ตามชื่อของทรัพยากร) จะรวม API ต่างๆ ของการดึงข้อมูลและแคชที่มีฮุกไว้ในวงจร นี่คือกลไกที่ทำให้ปลั๊กอินทำงานได้ในปัจจุบัน แต่นักพัฒนาซอฟต์แวร์ยังไม่เห็น

คลาส "เครื่องจัดการ" ใหม่ StrategyHandler จะแสดงเมธอดเหล่านี้เพื่อให้กลยุทธ์ที่กำหนดเองเรียกใช้ fetch() หรือ cacheMatch() และมีการเรียกใช้ปลั๊กอินที่เพิ่มลงในอินสแตนซ์กลยุทธ์โดยอัตโนมัติได้

คลาสนี้ยังทำให้นักพัฒนาซอฟต์แวร์เพิ่มการเรียกกลับในวงจรที่กำหนดเองได้ ซึ่งอาจเจาะจงสำหรับกลยุทธ์ของตน และ "ทำงานได้" ด้วยอินเทอร์เฟซปลั๊กอินที่มีอยู่

สถานะวงจรของปลั๊กอินใหม่

ใน Workbox v5 ปลั๊กอินจะไม่เก็บสถานะ ซึ่งหมายความว่าหากคำขอสำหรับ /index.html ทริกเกอร์ทั้งโค้ดเรียกกลับ requestWillFetch และ cachedResponseWillBeUsed โค้ดเรียกกลับทั้งสองจะไม่มีวิธีสื่อสารถึงกัน หรือแม้กระทั่งรู้ว่ามีการทริกเกอร์โดยคำขอเดียวกัน

ใน v6 โค้ดเรียกกลับของปลั๊กอินทั้งหมดจะได้รับการส่งผ่านออบเจ็กต์ state ใหม่ด้วย ออบเจ็กต์สถานะนี้จะไม่ซ้ำกันสำหรับออบเจ็กต์ปลั๊กอินที่เจาะจงและการเรียกใช้กลยุทธ์เฉพาะนี้ (เช่น การเรียกไปยัง handle()) ซึ่งจะช่วยให้นักพัฒนาซอฟต์แวร์เขียนปลั๊กอินที่โค้ดเรียกกลับหนึ่งสามารถดำเนินการบางอย่างตามเงื่อนไขของโค้ดเรียกกลับอีกรายการในปลั๊กอินเดียวกัน (เช่น คำนวณเดลต้าระหว่างเวลาระหว่างการเรียกใช้ requestWillFetch และ fetchDidSucceed หรือ fetchDidFail)

โค้ดเรียกกลับในวงจรของปลั๊กอินใหม่

มีการเพิ่มการเรียกกลับในวงจรของปลั๊กอินใหม่เพื่อให้นักพัฒนาซอฟต์แวร์ใช้ประโยชน์จากสถานะวงจรของปลั๊กอินได้อย่างเต็มที่

• handlerWillStart: เรียกใช้ก่อนที่ตรรกะของเครื่องจัดการจะเริ่มต้นทำงาน โค้ดเรียกกลับนี้สามารถใช้เพื่อตั้งค่าสถานะตัวแฮนเดิลเริ่มต้นได้ (เช่น บันทึกเวลาเริ่มต้น)
• handlerWillRespond: เรียกใช้ก่อนที่เมธอด handle() ของกลยุทธ์จะแสดงการตอบกลับ โค้ดเรียกกลับนี้สามารถใช้เพื่อแก้ไขการตอบสนองดังกล่าวก่อนส่งคืนไปยังเครื่องจัดการเส้นทางหรือตรรกะที่กำหนดเองอื่นๆ
• handlerDidRespond: มีการเรียกหลังจากที่เมธอด handle() ของกลยุทธ์แสดงการตอบกลับ คุณสามารถใช้โค้ดเรียกกลับนี้เพื่อบันทึกรายละเอียดการตอบกลับสุดท้าย เช่น หลังการเปลี่ยนแปลงที่ทำโดยปลั๊กอินอื่นๆ
• handlerDidComplete: เรียกใช้หลังจากสัญญาขยายอายุการใช้งานที่เพิ่มลงในกิจกรรมจากการเรียกใช้กลยุทธ์นี้เรียบร้อยแล้ว โค้ดเรียกกลับนี้สามารถใช้เพื่อรายงานเกี่ยวกับข้อมูลที่จำเป็นต้องรอจนกว่าเครื่องจัดการจะเสร็จสิ้นเพื่อคำนวณ (เช่น สถานะการค้นพบแคช เวลาในการตอบสนองของแคช เวลาในการตอบสนองของเครือข่าย)
• handlerDidError: เรียกหากเครื่องจัดการไม่สามารถให้การตอบสนองที่ถูกต้องจากแหล่งที่มาใดๆ คุณสามารถใช้โค้ดเรียกกลับนี้เพื่อระบุเนื้อหา "สำรอง" เพื่อเป็นทางเลือกสำหรับข้อผิดพลาดของเครือข่าย

นักพัฒนาซอฟต์แวร์ที่ใช้กลยุทธ์ที่กำหนดเองก็ไม่ต้องกังวลเรื่องการเรียกใช้โค้ดเรียกกลับเหล่านี้เอง ซึ่งทั้งหมดนี้จัดการโดยคลาสฐาน Strategy ใหม่

ประเภท TypeScript ที่แม่นยำยิ่งขึ้นสำหรับเครื่องจัดการ

คำจำกัดความ TypeScript สำหรับเมธอด Callback ต่างๆ ได้รับการปรับให้เป็นมาตรฐาน ซึ่งน่าจะช่วยให้นักพัฒนาซอฟต์แวร์ที่ใช้ TypeScript ได้รับประสบการณ์ที่ดีขึ้นและเขียนโค้ดของตนเองเพื่อติดตั้งใช้งานหรือเรียกใช้เครื่องจัดการ

หน้าต่างกล่องงาน

เมธอด messageSkipWaiting() ใหม่

เราได้เพิ่ม Method ใหม่ messageSkipWaiting() ลงในโมดูล workbox-window เพื่อลดความซับซ้อนของขั้นตอนการบอกให้ Service Worker แบบ"กำลังรอ" เปิดใช้งาน โดยมีการปรับปรุงบางอย่างดังนี้

• โดยเรียกใช้ postMessage() ด้วยเนื้อหาข้อความมาตรฐานโดยปริยาย ซึ่งก็คือ {type: 'SKIP_WAITING'} ที่ Service Worker สร้างขึ้นโดย Workbox จะทำหน้าที่ตรวจสอบเพื่อทริกเกอร์ skipWaiting()
• โปรแกรมจะเลือก Service Worker ที่ถูกต้องที่ "กำลังรอ" โพสต์ข้อความนี้ แม้ว่าจะไม่ใช่ Service Worker เดียวกับที่ workbox-window ลงทะเบียนไว้ก็ตาม

การนําเหตุการณ์ "ภายนอก" ออกเพื่อให้ใช้พร็อพเพอร์ตี้ isExternal แทน

เหตุการณ์ "external" ทั้งหมดใน workbox-window ถูกนำออกแทนเหตุการณ์ "ปกติ" ที่มีการตั้งค่าพร็อพเพอร์ตี้ isExternal เป็น true วิธีนี้ช่วยให้นักพัฒนาแอปที่สนใจความแตกต่างดังกล่าวยังคงตรวจพบได้อยู่ และนักพัฒนาแอปที่ไม่จําเป็นต้องทราบจะไม่สนใจพร็อพเพอร์ตี้ดังกล่าว

สูตรอาหาร "เสนอการโหลดหน้าเว็บซ้ำสำหรับผู้ใช้" ของเครื่องมือทำความสะอาด

ด้วยการเปลี่ยนแปลงทั้ง 2 อย่างข้างต้น สูตร "เสนอการโหลดหน้าซ้ำสำหรับผู้ใช้" สามารถทำให้เข้าใจง่ายขึ้นได้

MULTI_LINE_CODE_PLACEHOLDER_0

การกำหนดเส้นทางกล่องงาน

ระบบจะส่งพารามิเตอร์บูลีนใหม่ sameOrigin ไปยังฟังก์ชัน matchCallback ที่ใช้ใน workbox-routing โดยจะตั้งค่าเป็น true หากเป็นคำขอสำหรับ URL ต้นทางเดียวกัน และจะตั้งค่าเป็น "เท็จ" หากไม่มีการส่งคำขอ

วิธีนี้ทำให้ข้อความต้นแบบทั่วไปง่ายขึ้น:

MULTI_LINE_CODE_PLACEHOLDER_1

matchOptions ในวันที่หมดอายุของกล่องทำงาน

ตอนนี้คุณสามารถตั้งค่า matchOptions ใน workbox-expiration ซึ่งจะส่งผ่านเป็น CacheQueryOptions ไปยังการเรียก cache.delete() ที่เกี่ยวข้อง (นักพัฒนาซอฟต์แวร์ส่วนใหญ่ไม่จำเป็นต้องดำเนินการนี้)

การแคชพื้นที่ทำงานล่วงหน้า

ใช้กลยุทธ์เวิร์กบ็อกซ์

workbox-precaching ได้รับการเขียนใหม่ให้ใช้ workbox-strategies เป็นฐาน การเปลี่ยนแปลงนี้ไม่ควรส่งผลให้เกิดการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ และจะทำให้เกิดความสอดคล้องในระยะยาวที่ดีขึ้นต่อวิธีที่โมดูลทั้งสองเข้าถึงเครือข่ายและแคช

ขณะนี้การแคชล่วงหน้าจะประมวลผลรายการทีละรายการ ไม่ใช่แบบกลุ่ม

workbox-precaching ได้รับการอัปเดตเพื่อให้มีการขอและแคชรายการในไฟล์ Manifest แบบแคชล่วงหน้าเพียงครั้งละ 1 รายการเท่านั้น แทนที่จะพยายามขอและแคชรายการทั้งหมดในคราวเดียว (ออกจากเบราว์เซอร์เพื่อหาวิธีควบคุม)

ซึ่งจะช่วยลดโอกาสที่จะเกิดข้อผิดพลาด net::ERR_INSUFFICIENT_RESOURCES ขณะแคชล่วงหน้าได้ และยังควรลดการแย่งชิงแบนด์วิดท์ระหว่างการแคชล่วงหน้าและคำขอที่มาพร้อมกันซึ่งมาจากเว็บแอป

PrecacheFallbackPlugin ทำให้ใช้โฆษณาสำรองแบบออฟไลน์ได้ง่ายขึ้น

ตอนนี้ workbox-precaching มี PrecacheFallbackPlugin แล้ว ซึ่งนำเมธอดอายุการใช้งาน handlerDidError ใหม่ที่เพิ่มไว้ในเวอร์ชัน 6 ไปใช้

ซึ่งจะช่วยให้คุณระบุ URL ที่แคชไว้ล่วงหน้าเป็น "โฆษณาสำรอง" สำหรับกลยุทธ์หนึ่งๆ ได้โดยง่ายในกรณีที่การตอบกลับจะไม่สามารถใช้งานได้ ปลั๊กอินจะจัดการการสร้างคีย์แคชที่ถูกต้องสำหรับ URL ที่แคชไว้ล่วงหน้า รวมถึงพารามิเตอร์การแก้ไขที่จำเป็น

ต่อไปนี้คือตัวอย่างการใช้การตอบกลับด้วย /offline.html ที่เก็บไว้ล่วงหน้าเมื่อกลยุทธ์ NetworkOnly สร้างการตอบกลับสำหรับคำขอการนำทางไม่ได้ กล่าวคือ แสดงหน้า HTML ออฟไลน์ที่กำหนดเอง

MULTI_LINE_CODE_PLACEHOLDER_2

precacheFallback ในการแคชรันไทม์

หากใช้ generateSW เพื่อสร้าง Service Worker แทนการเขียน Service Worker ด้วยตนเอง คุณสามารถใช้ตัวเลือกการกำหนดค่า precacheFallback ใหม่ใน runtimeCaching เพื่อทำงานเดียวกันนี้

{
  // ... 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