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

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

State management gọn gàng

Nâng cao trình độ làm state management Code state một cách lean hơn Có một cách khác khi tiếp cận bài toán trên frontend Mình có cơ hội tiếp xúc với một vài bạn khi mới bắt đầu làm frontend và mình thấy mọi người hầu hết đều gặp phải cùng một vấn đề: Viết logic trong state-management quá phức tạp, dẫn tới code vừa khó hiểu lại còn khó debug.

https://thanhle.blog/blog/state-management-gon-gang

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 🙃

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

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?

Bạn sẽ thấy ở đây mình break thành 2 phần:

Lưu state khi user ấn vào cái CheckBox

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

Code theo kiểu trên có các vấn đề

Phải define thêm 1 state mới (cục 💩 thứ 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)

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ụ

When to add state?

When to add state? by mihthanh27 using react, react-dom, react-scripts

https://codesandbox.io/s/when-to-add-state-9gitv8