Khi nào thì thêm state mới ở Frontend?

Tại sao nên đọc bài này?

  • Để không tạo thêm nhiều state nữa ⇒ Ít code ⇒ Ít bug ⇒ ngầu hơn 😎
  • Mindset khi làm state ở frontend
 
notion image
 
Khi bắt đầu làm frontend, mình hay suy nghĩ khi code một flow nào đó là: khi event đó được trigger thì cái làm cái gì tiếp theo để thể hiện cho đúng trên react.
Cái mindset này cực kì simple và mình thấy khá ổn khi suy nghĩ như vậy. Đề bài cho là khi nào counter > 3 thì đổi style thành màu đỏ. Ok vậy đầu tiên làm cái state là màu đen, xong thì coi thằng counter đó khi nào > 3 thì set state nó thành màu đỏ là xong. Quite simple
Flow lúc đó sẽ là:
Event → Handle event → Set new state
 
Mind set đó khá là tuyến tính tuy nhiên code kiểu như vậy thì lại không ổn lắm vì:
  • Nó tạo thêm nhiều state mới
  • Tạo thêm nhiều state mới thì dĩ nhiên là code phức tạp lên 🤔
  • Code phức tạp hơn thì dễ “trầm kẻm” hơn rồi 😰
  • “trầm kẻm” thì tâm lý không ổn, không ổn thì nhiều bug 🐞
  • Nhiều bug thì lại “trầm kẻm” hơn nữa 🤯
  • …v…v
 
Mindset sẽ khiến mình code gọn gàng hơn sẽ là
Event → set new state → Handle UI based on state
Đọc thêm bài mình viết về clean state
Bây giờ mình đọc lại bài này thì thấy hơi khó hiểu, nên cố tình hôm nay viết bài này để chữa cháy
 
Từ mindset mới này thì câu hỏi khi nào thì cần thêm state mới sẽ được trả lời như sau.

State chứa data response từ API

Cái này chắc chắn phải lưu vào state hay ít nhất là lưu vào đâu đó xong sau cắt một ít bỏ vào state rồi vì
Không có data lưu ở đâu đó thì lấy gì mà bỏ vào UI đặng mà render 🙃
 
notion image
 

State chứa async status

Ok bây giờ call api trong app thì phải hiện cái loading các thứ chứ nhỉ? Mục tiêu là để user biết được là cái app nó đang chạy chứ không phải bug freeze mọe luôn
notion image
 

State chứa event mà user trigger

Vậy user muốn thêm cái checkbox chỉ filter những thằng Todo của mình thôi thì sao?
notion image
 
Bạn sẽ thấy ở đây mình break thành 2 phần:
  1. Lưu state khi user ấn vào cái CheckBox
  1. Tính ra state mới dựa trên cái state vừa thêm vào
 

Tại sao phải làm vậy?

Comparing với kiểu code
Event → Handle event → Set new state
notion image
 
Code theo kiểu trên có các vấn đề
  1. Phải define thêm 1 state mới (cục 💩 thứ 1)
  1. Phải check lại những chỗ nào liên quan tới state mới cần render ra UI và sửa lại (cục 💩 thứ 2)
  1. Check lại tất cả các chỗ handle event để sửa code thêm logic cho state mới (cục 💩 thứ 3)
Kiểu trên còn có n biến thể ở các vũ trụ khác nhau nữa:
  • useEffect trên filterMineTodo - Cách này còn bad cho performance nữa
  • useEffect trên todo
  • v…v
 
Việc switch qua kiểu viết dưới đây sẽ hạn chế được các vấn đề gặp ở trên, và… gọn hơn
Event → set new state → Handle UI based on state
 

Tổng kết lại

Trong việc code web app thì state là một thứ cực kì quan trọng, bạn xử lý nó gọn gàng thì code bạn đẹp và chạy nhanh, bạn xử lý nó cồng kệch thì bạn bị nhiều bug, bạn bị “trầm kẻm”
Mỗi lần suy nghĩ khi thêm một state mới thì hãy hỏi rằng?
  • State này có dùng để chứa api response không?
  • State này có dùng để chứa async status không?
  • State này có dùng để chứa minimum event data từ user không?
Nếu câu trả lời là không thì có vẻ bạn đang hơi cồng kềnh rồi đó. Công thức trên là công thức chung khi làm state và nó là framework-independent, bạn có thể dùng nó trong React, Vuejs, Svelte, bla … bla
 
Code trong ví dụ

Loading Comments...

Follow me @cuthanh15