Kotlin MVI กับ MVVM สำหรับแอป Android ที่มีฟอร์มเยอะ: สถานะ UI

ทำไมแอป Android ที่มีฟอร์มเยอะถึงยุ่งได้เร็ว

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

ฟอร์มยังเปิดเผยบั๊กสถานะก่อนเพราะมันผสมกันหลายประเภทของสถานะพร้อมกัน: สถานะ UI (สิ่งที่เห็น), สถานะอินพุต (สิ่งที่ผู้ใช้พิมพ์), สถานะเซิร์ฟเวอร์ (สิ่งที่ถูกบันทึก) และสถานะชั่วคราว (สิ่งที่กำลังทำอยู่) เมื่อพวกนี้ไม่ตรงกัน แอปจะเริ่มดู “สุ่ม”: ปุ่มถูกปิด/เปิดผิดเวลา ข้อผิดพลาดเก่ายังอยู่ หรือหน้าจอกลับไปสถานะเดิมหลังหมุนจอ

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

UX ฟอร์มที่ดีปฏิบัติตามกฎง่ายๆ ไม่กี่ข้อ:

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

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

ทบทวนสั้นๆ: MVVM และ MVI ในภาษาง่ายๆ

ความแตกต่างจริงๆ ระหว่าง MVVM และ MVI คือการไหลของการเปลี่ยนแปลงผ่านหน้าจอ

MVVM (Model View ViewModel) มักเป็นแบบนี้: ViewModel ถือข้อมูลหน้าจอ เปิดเผยให้ UI (มักผ่าน StateFlow หรือ LiveData) และให้เมทอดเช่น save, validate, หรือ load UI เรียกฟังก์ชันของ ViewModel ตอนที่ผู้ใช้โต้ตอบ

MVI (Model View Intent) มักเป็นแบบนี้: UI ส่ง events (intents), reducer ประมวลผลพวกมัน และหน้าจอเรนเดอร์จากออบเจ็กต์สถานะเดียวนั่นคือสิ่งที่ UI ต้องการตอนนี้ Side effects (เครือข่าย, ฐานข้อมูล) ถูกทริกเกอร์ในทางที่ควบคุมและรายงานผลกลับมาเป็น events

วิธีจำง่ายๆ สำหรับแนวคิด:

• MVVM ถามว่า “ข้อมูลอะไรที่ ViewModel ควรเปิดเผย และควรมีเมทอดอะไรบ้าง?”
• MVI ถามว่า “มีเหตุการณ์อะไรเกิดขึ้นได้บ้าง และพวกมันเปลี่ยนสถานะหนึ่งไปยังอีกสถานะอย่างไร?”

ทั้งสองรูปแบบใช้ได้ดีสำหรับหน้าจอเรียบง่าย พอมีการตรวจข้ามฟิลด์ autosave retry และร่างออฟไลน์ คุณต้องมีกฎชัดเจนว่าใครเปลี่ยนสถานะได้เมื่อไร MVI บังคับใช้กฎพวกนั้นโดยดีเริ่มต้น MVVM ยังคงใช้งานได้ แต่ต้องมีวินัย: เส้นทางการอัปเดตที่สม่ำเสมอและการจัดการ one-off UI events อย่างระมัดระวัง (snackbars, navigation)

วิธีออกแบบสถานะฟอร์มโดยไม่ให้เกิดความประหลาดใจ

วิธีที่เร็วที่สุดที่จะเสียการควบคุมคือปล่อยให้ข้อมูลฟอร์มกระจายอยู่ในหลายที่: view bindings, flows หลายตัว และ boolean อีกตัวหนึ่ง หน้าจอที่มีฟอร์มเยอะจะคงทนเมื่อต้นทางของความจริงมีที่เดียว

รูปร่าง FormState ที่ใช้งานได้จริง

ตั้งเป้าที่จะมี FormState เดียวที่เก็บอินพุตดิบพร้อมธงที่อนุมานได้บางอย่างที่ไว้ใจได้ เก็บให้เรียบและครบ แม้มันอาจดูใหญ่ไปหน่อย

data class FormState(
  val fields: Fields,
  val fieldErrors: Map\u003cFieldId, String\u003e = emptyMap(),
  val formError: String? = null,
  val isDirty: Boolean = false,
  val isValid: Boolean = false,
  val submitStatus: SubmitStatus = SubmitStatus.Idle,
  val draftStatus: DraftStatus = DraftStatus.NotSaved
)

sealed class SubmitStatus { object Idle; object Saving; object Saved; data class Failed(val msg: String) }
sealed class DraftStatus { object NotSaved; object Saving; object Saved }

โครงนี้แยกการตรวจสอบระดับฟิลด์ (ต่ออินพุต) ออกจากปัญหาระดับฟอร์ม (เช่น “ยอดรวมต้อง > 0”) ธงอนุมานอย่าง isDirty และ isValid ควรคำนวณที่ที่เดียว ไม่ใช่ทำซ้ำใน UI

โมเดลความคิดที่ชัดเจนคือ: fields (สิ่งที่ผู้ใช้พิมพ์), validation (สิ่งที่ผิด), status (แอปกำลังทำอะไร), dirtiness (เปลี่ยนตั้งแต่ครั้งสุดท้ายที่บันทึก), และ drafts (มีสำเนาออฟไลน์หรือไม่)

ผลกระทบแบบครั้งเดียวควรอยู่ที่ไหน

ฟอร์มยังทริกเกอร์เหตุการณ์ครั้งเดียว: snackbars, navigation, แบนเนอร์ “saved” อย่าใส่พวกนี้ไว้ใน FormState ไม่งั้นมันจะเกิดอีกเมื่อหมุนจอหรือ UI subscribe ใหม่

ใน MVVM ให้ส่ง effects ผ่านช่องทางแยก (ตัวอย่างเช่น SharedFlow) ใน MVI ให้ทำเป็น Effects (หรือ Events) ที่ UI บริโภคครั้งเดียว การแยกแบบนี้ป้องกันข้อผิดพลาดผีและข้อความสำเร็จซ้ำ

การไหลของการตรวจสอบใน MVVM vs MVI

การตรวจสอบเป็นจุดที่หน้าจอฟอร์มเริ่มรู้สึกเปราะบาง ตัวเลือกสำคัญคือกฎอยู่ที่ไหนและผลลัพธ์ส่งกลับ UI อย่างไร

กฎซิงโครนัสง่ายๆ (ฟิลด์จำเป็น ความยาวขั้นต่ำ ขอบเขตตัวเลข) ควรรันใน ViewModel หรือชั้นโดเมน ไม่ใช่ใน UI เพื่อให้ทดสอบได้และสอดคล้อง

กฎอะซิงโครนัส (เช่น “อีเมลนี้ถูกใช้แล้วไหม?”) ซับซ้อนกว่า ต้องจัดการการโหลด ผลลัพธ์ล้าสมัย และกรณีที่ผู้ใช้พิมพ์ใหม่

ใน MVVM การตรวจสอบมักกลายเป็นการผสมของสถานะและเมทอดช่วย: UI ส่งการเปลี่ยนแปลง (อัปเดตข้อความ, การเปลี่ยนโฟกัส, คลิกส่ง) ไปที่ ViewModel; ViewModel อัปเดต StateFlow/LiveData และเปิดเผยข้อผิดพลาดต่อฟิลด์และ canSubmit ธรรมดา การตรวจแบบอะซิงมักเริ่มเป็น job แล้วอัปเดต loading flag และ error เมื่อเสร็จ

ใน MVI การตรวจสอบมักชัดเจนกว่า แบ่งหน้าที่ปฏิบัติได้จริงคือ:

• reducer รันการตรวจสอบซิงโครนัสและอัปเดตข้อผิดพลาดของฟิลด์ทันที
• effect ทำการตรวจสอบอะซิงและ dispatch ผลลัพธ์กลับมาเป็น intent
• reducer นำผลนั้นมาใช้เฉพาะเมื่อมันตรงกับอินพุตล่าสุดเท่านั้น

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

Optimistic UI และการบันทึกแบบอะซิงโครนัส

Optimistic UI หมายถึงหน้าจอทำเหมือนการบันทึกสำเร็จก่อนที่ตอบจากเครือข่ายจะมาถึง ในฟอร์ม นั่นมักหมายถึงปุ่ม Save เปลี่ยนเป็น “Saving...”, แสดงตัวบ่งชี้เล็กๆ ว่า “Saved” เมื่อเสร็จ และอินพุตยังสามารถใช้งานได้ (หรือถูกล็อกตามตั้งใจ) ขณะที่คำขอยังอยู่

ใน MVVM มักทำโดยสลับธงอย่าง isSaving, lastSavedAt, และ saveError ความเสี่ยงคือ drift: การบันทึกทับซ้อนกันอาจทำให้ธงเหล่านี้ไม่สอดคล้องกันได้ ใน MVI reducer อัปเดตออบเจ็กต์สถานะเดียว จึงมีโอกาสขัดแย้งน้อยกว่า

เพื่อหลีกเลี่ยงการส่งซ้ำและ race conditions ให้ถือว่าทุกการบันทึกคือเหตุการณ์ที่มีตัวระบุ หากผู้ใช้แตะ Save สองครั้งหรือแก้ไขระหว่างการบันทึก คุณต้องมีกฎว่า response ใดชนะ การป้องกันที่ใช้ได้ในทั้งสองรูปแบบ: ปิดปุ่ม Save ขณะบันทึก (หรือดีบาวน์การแตะ), แนบ requestId (หรือเวอร์ชัน) กับแต่ละบันทึกและละ response ที่ล้าสมัย, ยกเลิกงานที่รันเมื่ผู้ใช้ปิดหน้า, และกำหนดความหมายของการแก้ไขขณะบันทึก (คิวบันทึกอีกครั้ง หรือทำให้ฟอร์มเป็น dirty อีกครั้ง)

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

สถานะข้อผิดพลาดที่ผู้ใช้กู้คืนได้

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

จะช่วยได้ถ้าแยกข้อผิดพลาดตามที่ที่มันควรอยู่ รูปแบบที่ผิดกับอีเมลไม่เหมือนกับการที่เซิร์ฟเวอร์ล่ม

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

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

ความต่างของรูปแบบคือวิธีการแมปข้อผิดพลาดจากเซิร์ฟเวอร์กลับมาเป็นสถานะ UI ใน MVVM อัปเดตหลาย flows หรือหลายฟิลด์ได้ง่ายและอาจสร้างความไม่สอดคล้องโดยไม่ตั้งใจ ใน MVI มักนำผลตอบกลับของเซิร์ฟเวอร์มาใช้ในขั้นตอน reducer เดียวที่อัปเดต fieldErrors และ formError พร้อมกัน

นอกจากนี้ ให้ตัดสินใจว่าสิ่งไหนเป็นสถานะ และอะไรเป็นเหตุการณ์ครั้งเดียว ข้อผิดพลาด inline และ “submission failed” ควรเป็นสถานะ (ต้องอยู่หลังหมุนจอ) การกระทำครั้งเดียวเช่น snackbar, สั่น, หรือ navigation ควรเป็น effects

ร่างออฟไลน์และการกู้คืนฟอร์มที่กำลังทำอยู่

แอปที่มีฟอร์มเยอะมักรู้สึกว่า “ออฟไลน์” แม้เครือข่ายจะปกติดี ผู้ใช้สลับแอป OS ฆ่ากระบวนการ หรือสัญญาณหลุดกลางทาง ร่างช่วยให้ไม่ต้องเริ่มใหม่

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

สิ่งที่ควรเก็บส่วนใหญ่คืออินพุตดิบของผู้ใช้ (สตริงที่พิมพ์, id ที่เลือก, URI ของไฟล์แนบ) พร้อมเมตาดาต้าพอให้ merge อย่างปลอดภัยต่อมา: snapshot เซิร์ฟเวอร์ล่าสุดและตัวบ่งชี้เวอร์ชัน (updatedAt, ETag หรือการนับง่ายๆ) การตรวจสอบสามารถคำนวณใหม่เมื่อกู้คืน

การเลือกที่เก็บขึ้นกับความอ่อนไหวและขนาด ร่างเล็กๆ อยู่ใน preferences ได้ แต่ฟอร์มหลายขั้นตอนและไฟล์แนบควรอยู่ในฐานข้อมูลท้องถิ่น หากร่างมีข้อมูลส่วนบุคคล ให้ใช้ที่เก็บเข้ารหัส

คำถามสถาปัตยกรรมใหญ่คือแหล่งความจริงอยู่ที่ไหน ใน MVVM ทีมมัก persist จาก ViewModel เมื่อตัวฟิลด์เปลี่ยน ใน MVI การ persist หลัง reducer ทุกครั้งอาจง่ายกว่าเพราะคุณบันทึกสถานะที่เป็นเอกภาพหนึ่งชิ้น (หรือ Draft ที่ได้อนุมาน)

จังหวะ autosave สำคัญ การบันทึกทุกครั้งที่พิมพ์จะสร้างเสียงดัง ใช้ debounce สั้น (เช่น 300–800 ms) บวกบันทึกเมื่อเปลี่ยนขั้นตอนจะให้ผลดี

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

แบบทีละขั้นตอน: สร้างฟอร์มที่เชื่อถือได้ด้วยทั้งสองรูปแบบ

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

เขียนรายการการกระทำที่หน้าจอต้องตอบสนอง: พิมพ์, blur, submit, retry, และการนำทางขั้นตอน ใน MVVM พวกนี้กลายเป็นเมทอดของ ViewModel และการอัปเดตสถานะ ใน MVI พวกมันเป็น intents ชัดเจน

แล้วสร้างเป็นรอบเล็กๆ:

1. กำหนด events สำหรับวงจรชีวิตทั้งหมด: edit, blur, submit, save success/failure, retry, restore draft.
2. ออกแบบออบเจ็กต์สถานะเดียว: ค่าฟิลด์, ข้อผิดพลาดต่อฟิลด์, สถานะฟอร์มโดยรวม, และ "มีการเปลี่ยนแปลงที่ยังไม่บันทึก"
3. เพิ่มการตรวจสอบ: ตรวจเบาๆ ขณะแก้ไข ตรวจเข้มข้นตอนส่ง
4. เพิ่มกฎ optimistic save: อะไรเปลี่ยนทันที และอะไรทริกเกอร์ rollback
5. เพิ่มร่าง: autosave ด้วย debounce, กู้คืนเมื่อเปิด, แสดงแบนเนอร์เล็กๆ "ร่างถูกกู้คืน" เพื่อให้ผู้ใช้เชื่อถือ

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

ถ้าต้องการทำต้นแบบสถานะฟอร์มซับซ้อนก่อนเขียน Android UI แพลตฟอร์ม no-code อย่าง AppMaster สามารถใช้ตรวจสอบโฟลว์ได้ก่อน แล้วค่อยนำกฎเดียวกันไปทำใน MVVM หรือ MVI ด้วยความประหลาดใจน้อยลง

ตัวอย่างสถานการณ์: ฟอร์มรายงานค่าใช้จ่ายหลายขั้นตอน

สมมติฟอร์มรายงานค่าใช้จ่าย 4 ขั้น: รายละเอียด (วันที่ หมวดหมู่ จำนวนเงิน), อัปโหลดใบเสร็จ, โน้ต แล้วตรวจทานและส่ง หลังส่งจะแสดงสถานะการอนุมัติเช่น Draft, Submitted, Rejected, Approved ปัญหาที่ซับซ้อนคือการตรวจสอบ การบันทึกที่อาจล้มเหลว และการเก็บร่างเมื่อออฟไลน์

ใน MVVM ปกติจะเก็บ FormUiState ใน ViewModel (มักเป็น StateFlow) การเปลี่ยนแปลงฟิลด์แต่ละครั้งเรียกฟังก์ชัน ViewModel เช่น onAmountChanged() หรือ onReceiptSelected() การตรวจสอบรันเมื่อเปลี่ยน แยกขั้นตอน หรือส่ง โครงสร้างทั่วไปคืออินพุตดิบบวกข้อผิดพลาดต่อฟิลด์ กับธงอนุมานที่ควบคุมการเปิดใช้งาน Next/Submit

ใน MVI โฟลว์เดียวกันกลายเป็นชัดเจน: UI ส่ง intents เช่น AmountChanged, NextClicked, SubmitClicked, และ RetrySave reducer คืนสถานะใหม่ Side effects (อัปโหลดใบเสร็จ, เรียก API, แสดง snackbar) รันนอก reducer และป้อนผลกลับมาเป็น events

ในการใช้งานจริง MVVM ทำให้ง่ายเพิ่มฟังก์ชันและอัปเดต flow ได้เร็ว MVI ทำให้ยากจะข้ามขั้นการเปลี่ยนสถานะโดยไม่ตั้งใจเพราะทุกการเปลี่ยนต้องผ่าน reducer

ข้อผิดพลาดและกับดักที่พบบ่อย

บั๊กฟอร์มส่วนใหญ่เกิดจากกฎไม่ชัดเจนว่าใครเป็นเจ้าของความจริง เมื่อไรการตรวจสอบรัน และจะเกิดอะไรเมื่อผลอะซิงมือล่าช้า

ข้อผิดพลาดที่พบบ่อยที่สุดคือการผสมแหล่งความจริง หากฟิลด์ข้อความบางครั้งอ่านจาก widget บางครั้งจาก ViewModel และบางครั้งจากร่างที่กู้มา คุณจะเจอการรีเซ็ตแบบสุ่มและรายงานว่า “อินพุตหาย” เลือกสถานะ canonical เดียวสำหรับหน้าจอและอนุมานทุกอย่างจากมัน (domain model, แถวแคช, payload API)

กับดักง่ายๆ อีกอย่างคือสับสนระหว่าง state กับ events toast, navigation, หรือ “Saved!” เป็นครั้งเดียว ข้อความผิดพลาดที่ต้องอยู่จนกว่าผู้ใช้จะแก้เป็นสถานะ ผสมสองอย่างนี้ทำให้เกิดเอฟเฟกต์ซ้ำเมื่อหมุนจอหรือฟีดแบ็กหายไป

สองปัญหาความถูกต้องที่มักเจอ:

• ตรวจเข้มเกินไปทุกครั้งที่พิมพ์ โดยเฉพาะการตรวจที่แพง ใช้ debounce, ตรวจตอน blur, หรือเฉพาะฟิลด์ที่ touched
• ไม่จัดการผลลัพธ์อะซิงที่ออกมาไม่เรียงลำดับ หากผู้ใช้บันทึกสองครั้งหรือแก้ไขหลังบันทึก ผลเก่าจะเขียนทับใหม่เว้นแต่คุณจะใช้ request IDs (หรือ logic “ล่าสุดเท่านั้น”)

สุดท้าย ร่างไม่ใช่แค่ “บันทึก JSON” หากไม่มีการตั้งเวอร์ชัน การอัปเดตแอปอาจทำให้การกู้คืนพัง เพิ่มเวอร์ชันสคีมาและเรื่องย้ายข้อมูลแม้จะเป็นเรื่องง่ายๆ เช่น “ลบทิ้งและเริ่มใหม่” สำหรับร่างเก่าๆ

เช็คลิสต์ด่วนก่อนปล่อย

ก่อนถก MVVM vs MVI ให้แน่ใจว่าฟอร์มของคุณมีแหล่งความจริงเดียว หากค่าที่เปลี่ยนบนหน้าจอได้ ต้องอยู่ในสถานะ ไม่ใช่อยู่ใน widget หรือ flag ที่ซ่อนอยู่

การตรวจสอบก่อนปล่อยที่เป็นประโยชน์:

• สถานะรวมอินพุต ข้อผิดพลาดต่อฟิลด์ สถานะการบันทึก (idle/saving/saved/failed) และสถานะร่าง/คิว เพื่อให้ UI ไม่ต้องเดา
• กฎการตรวจสอบเป็น pure และทดสอบได้โดยไม่ต้องแตะ UI
• Optimistic UI มีทางย้อนกลับเมื่อเซิร์ฟเวอร์ปฏิเสธ
• ข้อผิดพลาดไม่ลบอินพุตผู้ใช้
• การกู้คืนร่างคาดเดาได้: มีแบนเนอร์ auto-restore ชัดเจนหรือปุ่ม “กู้คืนร่าง” ที่ชัดเจน

การทดสอบอีกข้อที่จับบั๊กจริงๆ ได้: เปิด airplane mode ขณะบันทึก ปิดแล้วลองอีกครั้งสองครั้ง การลองครั้งที่สองไม่ควรสร้างรายการซ้ำ ใช้ request ID, idempotency key, หรือเครื่องหมาย “pending save” ท้องถิ่นเพื่อให้การลองใหม่ปลอดภัย

ถ้าคำตอบไม่ชัดเจน ให้กระชับโมเดลสถานะก่อน แล้วเลือกรูปแบบที่ทำให้กฎเหล่านั้นบังคับใช้ได้ง่ายที่สุด

ขั้นตอนต่อไป: เลือกเส้นทางและสร้างเร็วขึ้น

เริ่มด้วยคำถามเดียว: ถ้าฟอร์มของคุณตกอยู่ในสถานะกึ่งอัปเดต ความเสียหายจะมากแค่ไหน? ถ้าต่ำ ให้ทำให้เรียบง่าย

MVVM เหมาะเมื่อหน้าจอไม่ซับซ้อนมาก สถานะส่วนใหญ่อยู่ในรูปแบบ “ฟิลด์ + ข้อผิดพลาด” และทีมของคุณเชี่ยวชาญการส่งกับ ViewModel + LiveData/StateFlow

MVI เหมาะเมื่อคุณต้องการการเปลี่ยนสถานะที่เข้มงวดมาก ฯลฯ มีงานอะซิงจำนวนมาก (autosave, retry, sync) หรือบั๊กมีค่าใช้จ่ายสูง (การชำระเงิน, ข้อกำหนดด้านกฎระเบียบ, กระบวนการสำคัญ)

ไม่ว่าจะเลือกแบบไหน การทดสอบที่ให้ผลสูงสุดมักไม่ต้องแตะ UI: edge cases ของ validation, การเปลี่ยนสถานะ (edit, submit, success, failure, retry), rollback ของ optimistic save, และการกู้คืนร่างพร้อมพฤติกรรม conflict

ถ้าคุณต้องการ backend, หน้าผู้ดูแล และ API ควบคู่กับแอปมือถือ AppMaster (appmaster.io) สามารถสร้าง backend, เว็บ และแอปเนทีฟจากโมเดลเดียวกัน ช่วยให้กฎการตรวจสอบและโฟลว์สอดคล้องกันข้าม surface ได้ง่ายขึ้น.