เหตุผลที่ดีบาวซ์และธรอตเทิลสำคัญต่อ UI

เหตุการณ์ DOM บางชนิดเกิดขึ้นด้วยความถี่สูงมาก เหตุการณ์ keypress เกิดขึ้นทุกครั้งที่กดแป้นพิมพ์ เหตุการณ์ scroll เกิดขึ้นหลายสิบครั้งต่อวินาทีขณะเลื่อน และเหตุการณ์ resize เกิดขึ้นต่อเนื่องขณะที่ผู้ใช้ลากขอบหน้าต่าง การประมวลผลทุกเหตุการณ์แยกกันอาจทำให้ทั้งเบราว์เซอร์และเซิร์ฟเวอร์ของคุณรับภาระมากเกินไป

หากตัวจัดการการกดแป้นพิมพ์ของคุณส่งคำขอไปยังเซิร์ฟเวอร์ทุกครั้งที่กดแป้น ผู้ใช้ที่พิมพ์คำค้นหา 11 อักขระจะทำให้เกิดคำขอเครือข่าย 11 ครั้ง ซึ่งส่วนใหญ่เป็นคำค้นหาที่ยังไม่สมบูรณ์ ในทำนองเดียวกัน การอัปเดตภาพเคลื่อนไหวพารัลแลกซ์ทุกครั้งที่เลื่อนผ่านแต่ละพิกเซลจะทำให้เกิดการวาดใหม่ของรีแอ็กต์หลายร้อยครั้งต่อวินาที การทำเช่นนี้สิ้นเปลือง CPU เครือข่าย และแบตเตอรี่

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

ทรอตเทิลจำกัดการทำงานให้เกิดขึ้นได้ไม่เกินหนึ่งครั้งต่อช่วงเวลา ไม่ว่าจะมีเหตุการณ์เกิดขึ้นกี่ครั้งก็ตาม หากผู้ใช้เลื่อนอย่างรวดเร็ว การใช้ทรอตเทิลที่กำหนดไว้ 100 มิลลิวินาทีจะทำให้ตัวจัดการทำงานไม่เกิน 10 ครั้งต่อวินาที ทรอตเทิลตอบคำถามว่า: "ให้ทำสิ่งนี้เป็นระยะ แต่ไม่ถี่กว่าทุก N มิลลิวินาที"

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

ทรอตเทิลเป็นตัวเลือกที่เหมาะสมเมื่อคุณต้องการอัปเดตเป็นระยะระหว่างกิจกรรมที่ดำเนินต่อเนื่อง กรณีคลาสสิก ได้แก่ ตัวจัดการตำแหน่งการเลื่อน (อัปเดตแถบความคืบหน้าการอ่านหรือส่วนหัวแบบติดหนึบสูงสุด 30 เฟรมต่อวินาที) การติดตามการเคลื่อนเมาส์ (บันทึกตำแหน่งเคอร์เซอร์สำหรับการวิเคราะห์) และตัวจัดการเหตุการณ์ลาก (อัปเดตตำแหน่งองค์ประกอบที่ลากได้อย่างราบรื่นโดยไม่ส่งเหตุการณ์มากเกินไป)

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

โลแดชมี _.debounce(fn, wait) และ _.throttle(fn, wait) พร้อมตัวเลือกสำหรับการทำงานที่ขอบต้นและขอบท้าย ฟังก์ชันที่คืนค่ามามีเมธอด .cancel() สำหรับยกเลิกการเรียกใช้ที่รอดำเนินการ และเมธอด .flush() สำหรับเรียกใช้ทันที ในรีแอ็กต์ควรห่อฟังก์ชันเหล่านี้ไว้ใน useRef เพื่อหลีกเลี่ยงการสร้างใหม่เมื่อเกิดการวาดใหม่

แม้การวาดใหม่ของรีแอ็กต์เพิ่มอีก 50 ครั้งต่อวินาทีจากตัวจัดการการเลื่อนที่ไม่มีการจำกัดความถี่ก็อาจใช้ CPU อย่างมาก โดยเฉพาะบนอุปกรณ์เคลื่อนที่ประสิทธิภาพต่ำ งบประมาณต่อเฟรม 16 มิลลิวินาที (60 เฟรมต่อวินาที) หมายความว่าการวาดใหม่แต่ละครั้งต้องเสร็จภายใน 16 มิลลิวินาทีเพื่อหลีกเลี่ยงเฟรมที่หายไป ดีบาวซ์และทรอตเทิลคือแนวป้องกันด่านแรกของคุณต่อปัญหาอัตราเฟรม

ตัวจัดการเหตุการณ์ความถี่สูงทุกตัวไม่จำเป็นต้องใช้ดีบาวซ์ หากตัวจัดการเหตุการณ์เพียงอ่านค่าโดยไม่อัปเดตสถานะหรือเรียกใช้บริการ เช่น บันทึกตำแหน่งเมาส์ล่าสุดไว้ในการอ้างอิง ก็ไม่จำเป็นต้องใช้ดีบาวซ์ ควรใช้ดีบาวซ์หรือทรอตเทิลเฉพาะกับตัวจัดการที่เรียกใช้การดำเนินการซึ่งใช้ทรัพยากรมาก เช่น การอัปเดตสถานะ การเรียกใช้บริการ หรือการวัด DOM

เมื่อถอดคอมโพเนนต์ออก ควรยกเลิกการเรียกใช้ดีบาวซ์ที่รอดำเนินการเพื่อป้องกันการอัปเดตสถานะหลังจากถอดคอมโพเนนต์แล้ว หากใช้ useRef เก็บฟังก์ชันดีบาวซ์ไว้ ให้เรียกใช้ debouncedFn.cancel() ในการล้างข้อมูลของ useEffect ฟังก์ชันดีบาวซ์ของโลแดชมีเมธอดนี้ไว้สำหรับจุดประสงค์ดังกล่าวโดยเฉพาะ

ควรใช้เทคนิคใดเพื่อส่งคำขอไปยังเซิร์ฟเวอร์เมื่อผู้ใช้หยุดพิมพ์ในช่องค้นหา

เหตุการณ์ความถี่สูง เช่น keypress scroll และ resize อาจทำให้เกิดปัญหาด้านประสิทธิภาพหากตัวจัดการทำงานทุกครั้งที่เกิดเหตุการณ์ ดีบาวซ์จะรอให้ไม่มีเหตุการณ์เกิดขึ้น และเหมาะที่สุดสำหรับช่องป้อนคำค้นหาและตัวจัดการการปรับขนาด ทรอตเทิลจำกัดความถี่ และเหมาะที่สุดสำหรับการเลื่อนและการลาก ใช้การนำไปใช้จากโลแดชที่เก็บไว้ในการอ้างอิง และยกเลิกเสมอเมื่อถอดคอมโพเนนต์ออก