SydexaSydexa
Trang chủKhoá họcBài viết
Liệu React Context có thực sự thay thế được Redux/Zustand không?
Frontend

Liệu React Context có thực sự thay thế được Redux/Zustand không?

Hải Phương
|
16/11/2025
|
6 phút đọc

Mỗi khi bắt đầu setup một dự án mới, tôi luôn tự hỏi bản thân một câu hỏi: “React Context có đủ để quản lý trạng thái trang dự án này không? Liệu có cần sử dụng Redux hoặc Zustand không?”

Liệu chúng ta có thể quản lý trạng thái của ứng dụng chỉ bằng việc sử dụng bộ thư viện của React mà không cần thêm bất kỳ thư viện bên thứ ba nào không? Suy cho cùng, Context là của chính React, Redux thì quá nặng, Zustand thì lại quá mới và đòi hỏi phải học thêm nhiều.

Tôi cũng đã đem băn khoăn này đi hỏi anh Leader và nhận được câu trả lời rằng:

“React Context chưa bao giờ thay thế được Redux/Zustand. Chúng giải quyết những vấn đề hoàn toàn khác nhau.”

Hãy cũng tôi đi sâu hơn vào vấn đề này nhé

Mục đích của Context là gì?

Để hiểu tại sao Context không thể bị thay thế, chúng ta cần quay thời điểm bắt đầu , xem xem đội ngũ React đã thiết kế Context là để giải quyết vấn đề gì.

Mục đích ban đầu của Context là giải quyết vấn đề Dependency Injection. Mục tiêu của nó là cho phép các component con cháu sâu trong cây component có thể dễ dàng lấy dữ liệu từ component ở cấp cao nhất, từ đó tránh được việc truyền thuộc tính qua từng cấp (prop drilling).

Hãy xem qua ví dụ này:

Trong khi đó, Context giống như một đường ống, cho phép component Button có thể lấy trực tiếp dữ liệu mà component App cung cấp:

Vậy nếu dùng Context để quản lý trạng thái thay đổi thường xuyên thì sao?

Vấn đề sẽ nảy sinh ở đây. Nhiều người thấy việc Context có thể chia sẻ dữ liệu , liền ngộ nhận có thể dùng nó cho mọi công việc quản lý trạng thái toàn cục, đặc biệt là những trạng thái biến đổi thường xuyên.

Lúc này, nhược điểm của Context lộ rõ: Re-render không cần thiết.

Khi value của Provider trong Context thay đổi, tất cả các component con dùng Context này, bất kể nó có thực sự sử dụng phần dữ liệu bị thay đổi hay không, đều sẽ bị re-render. (React được thiết kế như vậy mà 🤷‍♂️).

Ví dụ:

Trong ví dụ này, khi bạn click vào nút "Add to Cart", setCart được gọi, AppProvider re-render. Bạn sẽ thấy trong console, cả UserInfo re-rendered! và AddToCartButton re-rendered! đều được in ra cùng lúc.

Mặc dù object user không hề thay đổi, nhưng vì object value bao bọc này mỗi lần đều là một tham chiếu mới, dẫn đến tất cả consumers đều bị ép buộc re-render. Component UserInfo đã thực hiện một lần render hoàn toàn vô nghĩa. Trong một ứng dụng lớn, kiểu render không cần thiết này sẽ nhanh chóng dẫn đến các vấn đề hiệu năng nghiêm trọng.

Vậy Redux/Zustand giải quyết vấn đề này như thế nào?

Redux và Zustand - những thư viện quản lý trạng thái chuyên nghiệp - có cốt lõi nằm ở Selector và Subscription.

Chúng giải quyết tận gốc điểm yếu của Context: cho phép component chỉ đăng ký vào đúng dữ liệu mà nó thực sự quan tâm.

Hãy lấy ví dụ với Zustand vì nó ngắn gọn hơn:

Bây giờ, khi bạn click vào nút và gọi addToCart, chỉ có trạng thái cart thay đổi.

Bên trong Zustand sẽ kiểm tra và phát hiện component <UserInfo /> đăng ký vào state.user.name không hề thay đổi, vì vậy nó sẽ không thông báo cho <UserInfo /> re-render!

Bạn sẽ chỉ thấy trong console dòng AddToCartButton re-rendered! (vì nó đăng ký vào hàm addToCart, địa chỉ hàm này không đổi, nên thường chỉ render một lần khi khởi tạo).

Đây chính là giá trị cốt lõi của các thư viện quản lý trạng thái chuyên nghiệp: thông qua việc đăng ký và lựa chọn chính xác, chúng thực hiện cập nhật trong phạm vi tối thiểu, tránh lãng phí hiệu năng.

Nên lựa chọn cái nào cho dự án?

Khi nào NÊN dùng React Context?

  • Dữ liệu toàn cục, cập nhật ít: Ví dụ: theme (giao diện), thông tin xác thực người dùng (tên, vai trò), cấu hình i18n (quốc tế hóa). Những dữ liệu này thường không thay đổi sau khi ứng dụng khởi chạy, hoặc thay đổi rất ít.
  • Dependency injection thuần túy: Truyền xuống các component con một instance API client không đổi, một instance công cụ ghi log, v.v.

Khi nào NÊN dùng Zustand (hoặc Redux)?

  • Trạng thái toàn cục phức tạp, cập nhật nhiều: Ví dụ: trạng thái giỏ hàng, trạng thái form phức tạp, dữ liệu ứng dụng chỉnh sửa hợp tác, dữ liệu real-time từ WebSocket.
  • Trạng thái được chia sẻ giữa các component và cần được kiểm soát render một cách tinh vi.
  • Khi cần sử dụng các tính năng nâng cao như middleware: Ví dụ: ghi log, xử lý Action bất đồng bộ, v.v.

Tóm lại:

  • React Context là một công cụ dependency injection chính chủ.
  • Zustand/Redux là một trình quản lý trạng thái (state manager).

Việc dùng Context như một trình quản lý trạng thái, đôi khi cũng "chạy được", nhưng trong hầu hết trường hợp, nó sẽ biến mọi thứ thành một mớ hỗn độn và kết quả không mấy lí tưởng.

Ngoài ra nếu muốn đào sâu hơn nữa, học các kiến thức chuyên sâu thực tiễn hơn từ giảng viên là chuyên gia có hơn 10 năm kinh nghiệm frontend và từng là kỹ sư tại Shopee Singapo thì bạn có thể tham khảo khoá học React Nâng Cao bên dưới của Sydexa nha!

React Nâng Cao - Chuyên Sâu với Tối Ưu Hiệu Năng
Khóa học React từ cơ bản đến nâng cao với chuyên gia. Trở thành Senior React Developer với Sydexa.
SydexaSydexa Team

Bài viết liên quan

Đừng đổ lỗi cho tối ưu hiệu năng nữa: Ứng dụng của bạn giật lag, có thể là do thiết kế sản phẩm quá tệ
Frontend
17/03/2026 · 8 phút đọc

Đừng đổ lỗi cho tối ưu hiệu năng nữa: Ứng dụng của bạn giật lag, có thể là do thiết kế sản phẩm quá tệ

Chắc hẳn mỗi khi chúng ta code xong một trang web và deploy lên production thì có một điều chúng ta khá quan tâm là Tối ưu hiệu năng (Performance Optimization). Trên mạng có nhiều bài viết chứa những thuật ngữ nghe rất đao to búa lớn: * Sử dụng Virtual List (danh sách ảo) để tối ưu việc render danh sách dài... * Sử dụng Web Worker để đẩy các tính toán phức tạp ra khỏi luồng chính (main thread)... * Sử dụng WASM để viết lại thuật toán lõi... Sau khi viết vài bài về tối ưu hiệu năng, cũng nh

Chi tiết bài viết
Chuyện gì thực sự xảy ra ở trình duyệt sau khi nhấn F5?
Frontend
11/03/2026 · 11 phút đọc

Chuyện gì thực sự xảy ra ở trình duyệt sau khi nhấn F5?

Trong lập trình frontend, "làm mới trang" trông có vẻ là một thao tác đơn giản, nhưng ẩn sau đó là một luồng phối hợp phức tạp giữa giao tiếp mạng (network communication), chiến lược cache (caching strategy) và engine render (rendering engine). Đặc biệt là khi nhấn F5, nó không phải là "tải lại hoàn toàn", cũng không phải là "dùng trực tiếp cache ở local", mà là một cơ chế xác thực thông minh nằm giữa hai trạng thái này. Để thực sự làm chủ các kỹ năng tối ưu hóa hiệu năng và debug frontend, bạn

Chi tiết bài viết
Server DTO: Nên giữ nguyên hay chuyển đổi?
Frontend
04/03/2026 · 12 phút đọc

Server DTO: Nên giữ nguyên hay chuyển đổi?

Trong các dự án mà Backend và Frontend được phát triển hoàn toàn tách biệt, chắc hẳn không ít lần chúng ta phải đau đầu với câu hỏi: "Dữ liệu server trả về thì nên xài luôn hay phải xào nấu lại?". Nếu dạo quanh các diễn đàn công nghệ hay đọc các bài thảo luận trên mạng, bạn sẽ thấy cuộc tranh luận về cách xử lý dữ liệu từ API này dường như chưa bao giờ có hồi kết. Cốt lõi của vấn đề luôn xoay quanh hai luồng quan điểm cực kỳ quen thuộc: "Dữ liệu backend trả về sao thì cứ tận dụng nguyên xi như

Chi tiết bài viết
Đừng lạm dụng useMemo nữa! Đây mới là Best Practice chuẩn xác dành cho bạn
Frontend
25/02/2026 · 12 phút đọc

Đừng lạm dụng useMemo nữa! Đây mới là Best Practice chuẩn xác dành cho bạn

useMemo là một React Hook giúp chúng ta ghi nhớ kết quả tính toán giữa các lần render để tối ưu hiệu năng trong một số trường hợp. Tuy nhiên, có một thực trạng đang diễn ra: người không biết thì chẳng bao giờ dùng, còn người đã biết thì lại lạm dụng nó ở mọi lúc, mọi nơi. Bài viết này sẽ giúp bạn hiểu rõ thực sự thì trong những trường hợp nào chúng ta mới nên sử dụng useMemo. Cú pháp tổng quát: useMemo hoạt động như thế nào? Ở lần render đầu tiên, useMemo sẽ thực thi hàm calculateValue (khôn

Chi tiết bài viết
Sydexa
Sydexa
SydexaSydexa

Nền tảng học lập trình với animation trực quan và bài tập tương tác, giúp bạn hiểu sâu thay vì chỉ đọc lý thuyết.

Sydexa FanpageBackend GroupFrontend Group

We learn, We share, We grow

Powered By
Cộng đồng System Design Việt Nam

contact@sydexa.com
0971489013