State​ ​Management​ ​คือ​อะไร​ ​และ​เมื่อ​ใด​จึง​จำเป็น​ใน​ ​Web​ ​Application

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

แยกชนิดของ State ก่อน

State เฉพาะส่วนประกอบ เช่น เปิดเมนูหรือไม่ มักเก็บใกล้ส่วนที่ใช้ State ที่ต้องแชร์ระหว่างหน้าควรพิจารณาว่าควรอยู่ใน URL หรือส่วนกลาง ส่วนข้อมูลจาก Server เช่น สถานะคำขอ ต้องมีกฎเรื่องโหลดใหม่ Cache และการอัปเดตหลังแก้ อย่านำข้อมูลทุกชนิดใส่ Global Store เพราะจะเพิ่มการประสานงานที่ไม่จำเป็น

ภาพที่ 1: เริ่มจากเจ้าของข้อมูลและอายุของข้อมูล ก่อนเลือกวิธีแชร์ State ระหว่างหน้าจอ

ตัวอย่างสมมติ: หน้ารายการงาน

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

เมื่อไรควรใช้เครื่องมือเพิ่ม

ถ้า State อยู่ในหน้าเดียวหรือแชร์ไม่กี่ส่วน การใช้ความสามารถพื้นฐานของ Framework มักพอ หากหลายหน้าต้องแก้ข้อมูลเดียวกัน มีการอัปเดตซับซ้อน หรือมี Cache ฝั่ง Client ที่ต้องจัดการจริง จึงประเมินเครื่องมือเพิ่มโดยดูปัญหาที่วัดได้ React แนะนำให้ลด State ซ้ำและยก State ไปยังเจ้าของร่วมที่ใกล้ที่สุดก่อน

สำหรับรายงาน

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

อ่าน Frontend Development และ React กับ Angular หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ แผนแบ่ง UI State, Form State, URL State และ Server Data ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• React: Managing State — การจัด State และลดข้อมูลซ้ำ