State Management

State management คือคำถามเดียว

มี package สำหรับ state management เป็นสิบ และมีศึกใน blog อีกเป็นร้อย แต่ทั้งหมดตอบคำถามเดียวกันที่แบ่งเป็นสองส่วน:

state ชิ้นนี้อยู่ที่ไหน และ widget ตัวไหน rebuild เมื่อ state ชิ้นนี้เปลี่ยน?

อย่างอื่น — setState, InheritedWidget, Provider, Riverpod, BLoC — เป็นแค่กลไกคนละแบบที่ตอบคำถามนี้ พอมองแบบนี้แล้ว การเลือกใช้จะเลิกเป็นเรื่องพวกพ้องและกลายเป็นเรื่องของ scope

state สองแบบ

การแบ่งที่มีประโยชน์ที่สุดไม่ใช่ “ใช้ package ไหน” แต่เป็น state เข้าถึงได้ไกลแค่ไหน:

flowchart TB
  eph["Ephemeral state
(widget เดียว: checkbox,
text field, animation)"] --> local["setState
อยู่ใน State object เดียว"]
  app["App state
(shared: auth, cart,
settings, cached data)"] --> shared["InheritedWidget / Provider /
Riverpod / BLoC"]

Ephemeral state vs app state

Ephemeral (local) state เป็นของ widget เดียวและไม่มีใครอื่นสน — หน้าปัจจุบันของ PageView, checkbox ติ๊กหรือยัง, ค่า animation setState คือคำตอบที่ถูกและครบ การหยิบ global store มาใช้ตรงนี้คือ over-engineering
App (shared) state ถูกใช้โดย widget หลายตัวทั่ว tree — user ที่ login อยู่, shopping cart, theme, data ที่ fetch จาก API นี่คือที่ที่วิธีเฉพาะทางคุ้มค่า

bug จริงและ over-engineering ส่วนใหญ่มาจากการเอา state ไปวางผิดหมวด

โมดูลนี้ครอบคลุมอะไรบ้าง

บทเรียน	สิ่งที่คุณจะได้เรียนรู้
setState & lifecycle	rebuild เกิดขึ้นจริงอย่างไร และ State lifecycle
InheritedWidget	primitive ที่ทำให้ propagate state ลง tree ได้อย่างมีประสิทธิภาพ
Provider & Riverpod	วิธี shared-state ที่ ergonomic และใช้กันแพร่หลาย
BLoC & patterns	unidirectional data flow สำหรับ app ที่ซับซ้อน
Choosing an approach	decision guide และการ layer app