การย้อนกลับเมื่อเกิดข้อผิดพลาดและการแก้ไขข้อขัดแย้ง

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

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

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

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

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

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

สำหรับการขจัดรายการซ้ำที่ฝั่งเซิร์ฟเวอร์ ให้ใส่ส่วนหัว Idempotency-Key ที่ไม่ซ้ำกันในการเปลี่ยนแปลงข้อมูลแต่ละคำขอ สร้างคีย์ด้วย crypto.randomUUID() เมื่อผู้ใช้เริ่มการดำเนินการ เซิร์ฟเวอร์จะตรวจพบคีย์ที่ซ้ำกันและส่งคืนการตอบกลับเดียวกับคำขอเดิม โดยไม่ดำเนินการนั้นซ้ำ

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

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

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

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

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

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