คู่มือนี้เน้นการเปลี่ยนแปลงที่นำมาใช้ใน Workbox v6 พร้อมตัวอย่างการเปลี่ยนแปลงที่คุณจำเป็นต้องทำเมื่ออัปเกรดจาก Workbox v5
การเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ
แกนงาน
เมธอด skipWaiting()
ใน workbox-core
จะไม่เพิ่มในเครื่องจัดการ install
อีกต่อไป และเทียบเท่ากับการเรียกใช้ self.skipWaiting()
เท่านั้น
จากนี้ไป ให้ใช้ self.skipWaiting()
แทน เนื่องจากอาจมีการนำ skipWaiting()
ออกจาก Workbox v7 แล้ว
การแคชพื้นที่ทำงานล่วงหน้า
- เอกสาร HTML แบบข้ามต้นทางสำหรับ URL ที่สอดคล้องกับการเปลี่ยนเส้นทาง HTTP จะไม่สามารถใช้เพื่อตอบสนองคำขอการนำทางด้วย
workbox-precaching
ได้อีกต่อไป สถานการณ์นี้มักพบได้ไม่บ่อยนัก - ตอนนี้
workbox-precaching
จะไม่สนใจพารามิเตอร์การค้นหา URLfbclid
เมื่อค้นหาการตอบกลับที่แคชไว้ล่วงหน้าสําหรับคําขอหนึ่งๆ - ตอนนี้ตัวสร้าง
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