การข้าม @Stable และ @Immutable

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

@Immutable บอก Compose ว่า เมื่อสร้างอินสแตนซ์แล้ว คุณสมบัติทั้งหมดจะไม่เปลี่ยนแปลงอีก นี่คือการรับประกันความเสถียรระดับสูงสุด

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

@Stable มีข้อกำหนดผ่อนปรนกว่า: คุณสมบัติอาจเปลี่ยนแปลงได้ แต่เมื่อเปลี่ยน Compose จะได้รับการแจ้งผ่านสถานะของ Compose และ equals() ต้องยังคงให้ผลสอดคล้องกัน

ใช้ @Stable กับคลาสที่ฟิลด์เปลี่ยนแปลงได้อาศัย mutableStateOf เพื่อให้ Compose ติดตามการเปลี่ยนแปลงทุกครั้งได้อย่างถูกต้อง

คำอธิบายประกอบเหล่านี้คือ สัญญา หากระบุว่าชนิดข้อมูลเสถียรแต่แอบเปลี่ยนแปลงโดยไม่แจ้ง ระบบ UI จะแสดงข้อมูลเก่าและเกิดข้อผิดพลาดตามมา

แทนที่จะส่ง List ให้ส่ง ImmutableList จาก kotlinx.collections.immutable Compose จะมองว่าชนิดนี้เสถียร ดังนั้น Composable ที่แสดงรายการจึงสามารถถูกข้ามได้

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

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

ให้เลือกใช้ความ ไม่เปลี่ยนแปลงจริงด้วย val ก่อน ใส่คำอธิบายประกอบเฉพาะเมื่อคอมไพเลอร์ไม่สามารถอนุมานความเสถียรได้ด้วยตนเองจริง ๆ

หลังใส่คำอธิบายประกอบแล้ว ให้ตรวจสอบว่า Composable ถูกข้ามจริง คำสัญญาที่ผิดพลาดยิ่งแย่กว่าการไม่มีคำสัญญาเลย

ใช้ @Immutable กับข้อมูลที่ไม่เปลี่ยนแปลงเลย และใช้ @Stable กับข้อมูลที่เปลี่ยนแปลงได้ซึ่งมีสถานะรองรับ จงปฏิบัติตามสัญญา มิฉะนั้นระบบ UI จะแสดงข้อมูลไม่ตรงความจริง ✅