Skip to content

Instantly share code, notes, and snippets.

@thaod
Last active January 9, 2018 12:13
Show Gist options
  • Save thaod/65e1a79d7eec6b6b42b5a4b9054e63d2 to your computer and use it in GitHub Desktop.
Save thaod/65e1a79d7eec6b6b42b5a4b9054e63d2 to your computer and use it in GitHub Desktop.
Kể chuyện về React/Redux

Hỏi: Ae nghĩ gì về chuyện force immutability của React/Redux? Nguyên nhân? Hiệu quả? Có làm khác đi đc ko?

TL;DR: Tính chính xác trong kiến thức công nghệ của comment này không cao để trả lời rõ ràng câu hỏi trên, nên chủ yếu mình chỉ là kể lại những gì đã xảy ra để có thêm góc nhìn thôi :).

Dựa vào trải nghiệm đầu năm 2017 khi build dự án React/Redux làm về Fintech, gắn bó chừng 4 tháng:

Nguyên nhân: Đa số là nguyên nhân chủ quan.

Vì ngày đó Redux là “the one” trong giải pháp về states manament. Nên concept của nó như rứa thì phải theo.

Để hiểu rõ hơn thì xem ở link:

https://redux.js.org/docs/recipes/reducers/PrerequisiteConcepts.html

Tại thời điểm đó, với kiến thức và kinh nghiệm hạn chế thì cách hiểu của mình như sau:

  • Không thay đổi arguments: Mình hiểu là JS Object khi được truyền và và sử dụng trong các hàm, vẫn giữ nguyên reference. Cho nên lúc đó mình thay đổi gì thì object ở ngoài hàm cũng bị thay đổi theo. Tính chất này của JS Object khá là khó hiểu, khó debug và dễ gặp lỗi trong team của mình khi đó (các bạn là fresher).

Cho nên, quy tắc này của Redux có thể gián tiếp giúp cho mọi người nhớ và hiểu về nó. Ngoài ra, Redux state mình dùng để lưu data, nên nếu có chỗ nào chỉ cần hiển thị data một lần mà không cần cập nhật lại sẽ không vô tình bị thay đổi do reference.

  • Không tạo ra side effect: Cái này mình chỉ đọc sao biết vậy, chưa thực sự hiểu rõ và hình dung được lợi ích.

Tóm lại, mình dùng Redux để đơn giản hoá việc đọc, ghi shared data giữa các components với nhau. Còn lại chỉ là phải dùng nên ráng đọc hiểu Redux để khi dùng còn biết đường mà debug.

Vận dụng

Ngày đó, sai lầm lớn nhất mà mình nhận ra là tụi mình đã cho tất cả những gì gọi là data (cả shared và non-shared) vào trong Redux state tree. Có vẻ tới ngày nay, đây là điều đầu tiên mà mình thấy hay được mang ra debate khi dùng state management.

Cụ thể một số ví dụ là:

  • Form data:

    • Searchable suggestions <select>: Inital loaded data từ backend (BE) và search cũng gửi request đến BE replace lại data chứ không append

    • Form data dùng một lần cũng quăng vào state. Sau đó xài form xong thì gọi hàm để clear form data trong state. Lần tiếp theo dùng form thì load lại những initial data từ BE.

  • List data:

    • Data lúc nào cũng được load lại do filter, không share cho components nào nhưng cũng cho vào Redux state tree.
  • Child prop data

    • Chỉ là pass prop data cho child component mà cũng quăng vào state

Khó khăn

Do dùng không đúng nên khó khăn cũng từ đấy mà ra:

  • Mỗi một component cần update state là tương ứng với một hàm setState(). Số lượng code cứ vậy mà nhân lên.

VD:

Form data: Mỗi một input component thay đổi cần update form data là tương ứng với một hàm setState(). Mình làm FinTech nên một form thường 7 - 10 fields.

  • Mọi người trong team bị rối giữa React component state và Redux state

  • Gọi quá nhiều lần và vô tội vạ các hàm setState(), dispatch() làm trigger re-rendering, khiến JS stack và message queue của bị busy và làm block những async action cần handle từ user (click, scroll). Làm cho UI bị giật, freeze.

  • Vì setState của React là async, nên việc thay đổi state không thực sự kiểm soát được về thứ tự.

Có làm khác đi được không?

Do mình rời dự án đó ở giữa giai đoạn và những điều trên sau khi rời dự án mình mới nhận ra. Nên là cũng không thực sự giải quyết được vấn đề. Cũng không rõ các bạn trong team đã giải quyết được chưa, và như thế nào. Sau đó mình cũng không tiếp tục làm React, nên phần này mình chỉ nói dựa vào kiến thức chung về Frontend Dev. Mình nghĩ không cần Immutability trong trường hợp data chỉ cần dùng ở một nơi duy nhất.

JS Object reference vẫn có điểm tốt của nó. Đó là thứ mà đa số nghĩ là điểm yếu: có thể nhận được thay đổi của object đó ngay lập tức.

Trong Frontend, việc block và làm chậm user actions, data visualizations là vấn đề ảnh hưởng trực tiếp tới UX. Nên trong trường hợp data chỉ dùng một chỗ (VD như form data từ user input để create, update một record). Thì mình có thể tận dụng JS Object reference để nhận nhanh những data đó.

Còn lại, về shared data, nên dùng Immutability để tránh trường hợp data bị thay đổi trong quá trình tính toán, kết quả chưa phải là final để hiển thị hoặc gửi đi.

Kết

Đó là tất cả chia sẻ của mình về trải nghiệm của mình khi từng dùng React/Redux. Hầu hết đều là chủ quan vì mình tiếp xúc với React/Redux chưa được nhiều. Mong nghe chia sẻ thêm.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment