การประยุกต์ใช้จริง: การค้นหา การเลื่อน และการปรับขนาด

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

ให้แสดงตัวหมุนบอกสถานะกำลังโหลดทันทีที่ผู้ใช้เริ่มพิมพ์ ไม่ใช่รอจนคำขอไปยังบริการเริ่มทำงาน ให้กำหนด isLoading: true เมื่อใดก็ตามที่ inputValue !== debouncedQuery เนื่องจากค่าทั้งสองไม่ตรงกันขณะที่การหน่วงกำลังรออยู่ เมื่อคำค้นหาอยู่ตัวและการดึงข้อมูลเสร็จสิ้นแล้ว ให้เปลี่ยนค่ากลับเป็น false ผู้ใช้จึงเห็นตัวบ่งชี้การโหลดที่ตอบสนองตลอดกระบวนการ

เอฟเฟกต์พารัลแลกซ์หรือแถบความคืบหน้าการอ่านจะอัปเดตตามตำแหน่งการเลื่อน ให้จำกัดอัตราตัวจัดการการเลื่อนไว้สูงสุด 60 เฟรมต่อวินาทีโดยใช้การหน่วง 16 มิลลิวินาที: const throttledScrollY = useThrottle(scrollY, 16) ส่วนติดต่อผู้ใช้จะอัปเดตได้อย่างราบรื่นโดยไม่ต้องเสียทรัพยากรคำนวณตำแหน่งใหม่ทุกพิกเซลที่เลื่อน

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

เมื่อ debouncedQuery เปลี่ยนแปลง ให้สร้าง AbortController ใหม่และส่ง signal ไปยัง fetch(url, { signal }) ให้คืนฟังก์ชันล้างข้อมูลที่เรียก controller.abort() การทำเช่นนี้จะยกเลิกคำขอที่กำลังทำงานอยู่จากคำค้นหาก่อนหน้าเมื่อมีคำค้นหาใหม่ที่ผ่านการหน่วงเข้ามา จึงป้องกันภาวะการแข่งขันที่คำตอบจากคำขอเก่าซึ่งช้ากว่าเขียนทับคำตอบจากคำขอใหม่ที่เร็วกว่า

หากไม่มี AbortController เมื่อผู้ใช้พิมพ์ "re" แล้วรอ จากนั้นพิมพ์ "react" คำค้นหาที่สองอาจส่งคำตอบกลับมาก่อนคำค้นหาแรกเนื่องจากการแคช ผลการค้นหาจะแสดงผลลัพธ์ของ React ชั่วครู่ แล้วถูกเขียนทับด้วยผลลัพธ์เก่าของ "re" AbortController ป้องกันปัญหานี้โดยยกเลิกคำขอก่อนหน้าทั้งหมด

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

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

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

ค่าการหน่วงเป็นการตัดสินใจด้านประสบการณ์ผู้ใช้ สำหรับการค้นหา 200-300 มิลลิวินาทีช่วยสร้างสมดุลระหว่างการตอบสนองที่รวดเร็วกับการลดจำนวนคำขอ สำหรับการปรับขนาด 150-200 มิลลิวินาทีถือว่ายอมรับได้ เพราะผู้ใช้คาดหวังให้เค้าโครงนิ่งหลังปรับขนาดเสร็จ สำหรับการบันทึกอัตโนมัติ 1000 มิลลิวินาทีช่วยให้ผู้ใช้มีเวลาพิมพ์หนึ่งประโยคก่อนบันทึก ให้ปรับค่าตามความเร็วของการโต้ตอบที่คาดไว้

แอปจริงมักต้องใช้การปรับปรุงประสิทธิภาพหลายอย่างพร้อมกัน ตัวแก้ไขเอกสารอาจใช้ดีบาวน์สำหรับการบันทึกอัตโนมัติ (1 วินาที) ใช้ทรอตเทิลสำหรับการคำนวณจำนวนคำ (500 มิลลิวินาที) และใช้ IntersectionObserver สำหรับการวิเคราะห์ เทคนิคเหล่านี้ทำงานร่วมกันได้ดี เพราะแต่ละอย่างทำงานอย่างอิสระด้วยตัวจับเวลาของตนเองและในขอบเขตของตนเอง

เหตุใดจึงควรใช้ AbortController ร่วมกับคำค้นหาแบบดีบาวน์

ให้ใช้ useDebounce กับช่องค้นหา ตัวจัดการการปรับขนาด และการบันทึกแบบฟอร์มอัตโนมัติ ให้ใช้ useThrottle กับการเลื่อนและการเคลื่อนเมาส์ ควรใช้คำขอไปยังบริการที่ผ่านการหน่วงร่วมกับ AbortController เสมอ เพื่อป้องกันภาวะการแข่งขัน ให้แสดงสถานะกำลังโหลดทุกครั้งที่ inputValue !== debouncedQuery เพื่อให้ส่วนติดต่อผู้ใช้ตอบสนองและให้ข้อมูลแก่ผู้ใช้อย่างเหมาะสม