เจาะลึกการแทนที่ระบบแจ้งเตือนด้วย Promise ในแอป Munchable
เรียนรู้วิธีการแก้ปัญหาบั๊กการแสดงผล Dialog บน React Native และ iOS ผ่านระบบโฮสต์แบบซ้อนทับ พร้อมเทคนิคจัดการอนิเมชันตอนปิดหน้าต่าง

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- เปลี่ยนจากการใช้ Alert.alert สู่การใช้งาน awaitable API เพื่อการจัดการ Dialog ที่สมบูรณ์
- แก้ไขปัญหา UIKit ปฏิเสธการแสดงผลซ้อนบน iOS ด้วยระบบลงทะเบียนโฮสต์และเลือกโฮสต์ชั้นในสุด
- จัดการปัญหาข้อความหายระหว่างอนิเมชันเฟดเอาต์ด้วยการเก็บคำขอสุดท้ายไว้ใน ref
- เปิดให้ทดลองใช้งานผ่านเบราว์เซอร์ที่ app.munchable.app รวมถึงฟีเจอร์การจัดการข้อมูลส่วนตัว
การพัฒนาแอปพลิเคชันมักต้องเผชิญกับความท้าทายในการจัดการส่วนติดต่อผู้ใช้งาน โดยเฉพาะระบบกล่องข้อความแจ้งเตือน (Dialog) ที่ต้องทำงานได้อย่างแม่นยำในทุกสถานการณ์ บทความนี้บอกเล่าเรื่องราวเกี่ยวกับการปรับปรุงระบบแจ้งเตือนในแอปพลิเคชัน Munchable ซึ่งเข้ามาแทนที่วิธีการแบบเดิมด้วยระบบ Promise เพื่อให้มั่นใจว่าทุกการออกจากหน้าจอจะมีคำตอบกลับมาอย่างแน่นอน
ในส่วนแรก นักพัฒนาได้เปลี่ยนมาใช้ API แบบ awaitable แทนที่ Alert.alert แบบดั้งเดิม ส่งผลให้สัญญาการทำงานของสโตร์ไม่ใช่แค่การสั่งแสดงหน้าต่างอีกต่อไป แต่เป็นการจำกัดให้แสดงผลทีละหนึ่ง Dialog และทุกคำขอจะต้องได้รับการจัดการจนเสร็จสิ้นอย่างแม่นยำพอดี

ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
อย่างไรก็ตาม ความซับซ้อนที่แท้จริงเกิดขึ้นในส่วนที่สองซึ่งเกี่ยวข้องกับระบบปฏิบัติการ iOS โดยเฉพาะ เนื่องจากคอมโพเนนต์ <Modal> ใน React Native จะทำการพรีเซนต์จากวิวคอนโทรลเลอร์ที่ใกล้ที่สุด เมื่อหน้าจอหลักอย่าง capture, menu และ paywall เปิดใช้งานอยู่แล้ว วิวคอนโทรลเลอร์รากจึงมีการพรีเซนต์งานอื่นค้างไว้ หากโฮสต์ของ Dialog ถูกติดตั้งไว้แค่ที่รากของแอป ระบบจะพยายามสั่งพรีเซนต์ซ้ำเป็นครั้งที่สอง ซึ่ง UIKit จะปฏิเสธทันส่งผลให้ปุ่มบนหน้าจอผลลัพธ์ไม่ทำงานตามที่คาดไว้
การจัดการ Modal ใน React Native มักพบปัญหาข้อจำกัดของ UIKit บน iOS ที่ไม่อนุญาตให้พรีเซนต์ซ้อนทับกันโดยตรงในคอนโทรลเลอร์ตัวเดียวกัน การออกแบบสถาปัตยกรรมแบบให้คอมโพเนนต์ลูกลงทะเบียนตัวเองเพื่อทำหน้าที่เป็นโฮสต์แทนจึงเป็นแนวทางแก้ปัญหาที่ชาญฉลาดในการเลี่ยงข้อจำกัดของระบบปฏิบัติการพกพา
แนวทางแก้ไขคือการให้โฮสต์ทำการลงทะเบียนตัวเอง และจะแสดงผลเฉพาะโฮสต์ชั้นในสุดเท่านั้น โดยใช้ลำดับการเมานต์เข้ามาช่วยตรวจสอบสถานะ:
- ระบบโฮสต์จะบันทึกตามลำดับการเมานต์
- โฮสต์ชั้นในสุดจะทำหน้าที่เรนเดอร์เนื้อหา
- โฮสต์ระดับรากจะทำหน้าที่เป็นค่าสำรองสำหรับหน้าจอทั่วไป
สำหรับการจัดการเมื่อมีการยกเลิกการเมานต์ (unmount) ระบบจำเป็นต้องคำนึงถึงระยะเวลาของอนิเมชันเฟดเอาต์ที่กินเวลาไม่กี่ร้อยมิลลิกรัม หากอ่านค่าชื่อเรื่องและข้อความตรงจากตัวปัจจุบันทันที จะทำให้ข้อมูลว่างเปล่าระหว่างการเล่นอนิเมชัน ระบบจึงแก้ปัญหาโดยการเก็บคำขอสุดท้ายไว้ใน ref เพื่อให้ Dialog ที่กำลังจะหายไป ยังคงแสดงข้อความอยู่ครบถ้วนจนกระทั่งอนิเมชันสิ้นสุดลง
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น