Quản lý trạng thái Vue 3 cho admin panels: chọn giữa Pinia, provide/inject và state cục bộ bằng ví dụ thực tế như bộ lọc, nháp và tabs.
Các admin panel cảm giác nặng về state vì chúng gom nhiều phần chuyển động trên cùng một màn hình. Một bảng không chỉ là dữ liệu. Nó còn có sắp xếp, bộ lọc, phân trang, các hàng được chọn, và ngữ cảnh “vừa xảy ra gì” mà người dùng dựa vào. Thêm các form dài, quyền theo vai trò, và các hành động thay đổi quyền thao tác UI, thì những quyết định nhỏ về state bắt đầu có ý nghĩa.
Thách thức không phải là lưu giá trị. Mà là giữ cho hành vi dễ dự đoán khi nhiều component cần cùng một sự thật. Nếu một chip lọc nói Active, bảng, URL và hành động xuất dữ liệu phải đồng ý với nhau. Nếu người dùng sửa một bản ghi rồi rời đi, app không nên im lặng làm mất công việc của họ. Nếu họ mở hai tab, một tab không nên ghi đè tab kia.
Trong Vue 3, thường bạn sẽ chọn giữa ba nơi để giữ state:
Một cách hữu ích để nghĩ: với mỗi phần state, quyết định nơi lưu để nó luôn đúng, không làm người dùng bất ngờ, và không biến thành spaghetti.
Các ví dụ dưới đây bám vào ba vấn đề admin phổ biến: bộ lọc và bảng (cái gì nên tồn tại vs đặt lại), nháp và chỉnh sửa chưa lưu (form người dùng có thể tin tưởng), và chỉnh sửa đa tab (tránh va chạm state).
Các tranh luận về state sẽ dễ hơn khi bạn ngừng tranh luận về công cụ và trước hết đặt tên loại state bạn có. Các loại state khác nhau hành xử khác nhau, và trộn chúng là nguyên nhân tạo ra bug khó hiểu.
Phân tách thực dụng:
Rồi xác định phạm vi. Hỏi state được dùng ở đâu hôm nay, không phải có thể dùng ở đâu trong tương lai. Nếu nó chỉ quan trọng trong một component bảng, state cục bộ thường đủ. Nếu hai component anh em trên cùng một trang cần nó, vấn đề thực sự là chia sẻ ở mức trang. Nếu nhiều route cần, bạn đã vào vùng state dùng chung của app.
Tiếp theo là thời gian sống. Một số state nên đặt lại khi đóng drawer. State khác nên tồn tại qua điều hướng (bộ lọc khi bạn click vào một bản ghi rồi quay lại). Một số nên sống qua refresh (một nháp dài người dùng quay lại sau). Đối xử cả ba như nhau là cách bạn có bộ lọc vô lý bị đặt lại, hoặc nháp biến mất.
Cuối cùng, kiểm tra đồng thời. Admin panel nhanh chóng chạm vào các edge case: người dùng mở cùng một bản ghi ở hai tab, một làm mới nền cập nhật một hàng trong khi form đang dirty, hoặc hai người cùng tranh save.
Ví dụ: màn Users với bộ lọc, một bảng và một drawer chỉnh sửa. Bộ lọc là UI state với vòng đời trang. Rows là server state. Trường trong drawer là form state. Nếu cùng một user bị chỉnh sửa ở hai tab, bạn cần quyết định đồng thời rõ ràng: chặn, gộp, hay cảnh báo.
Khi bạn có thể gán nhãn state theo loại, phạm vi, thời gian sống và đồng thời, lựa chọn công cụ (cục bộ, provide/inject, hay Pinia) thường sẽ rõ ràng hơn.
Các lựa chọn state tốt bắt đầu với một thói quen: mô tả state bằng lời trước khi chọn công cụ. Admin panel trộn bảng, bộ lọc, form lớn và điều hướng giữa các bản ghi, nên ngay cả state “nhỏ” cũng có thể thành ổ bug.
Ai cần state này?
provide/inject.Bộ lọc là ví dụ tốt. Nếu chỉ ảnh hưởng một bảng, state cục bộ là ổn. Nếu bộ lọc nằm ở header nhưng điều khiển bảng bên dưới, chia sẻ ở mức trang (thường provide/inject) giữ mọi thứ gọn.
Nó phải tồn tại bao lâu?
Điều này quan trọng nhất với nháp. Chỉnh sửa chưa lưu nhạy cảm với lòng tin: người dùng mong nháp vẫn ở đó nếu họ rời rồi quay lại.
Nó có nên chia sẻ giữa các tab trình duyệt hay cô lập theo tab?
Chỉnh sửa đa tab là nơi ẩn bug. Nếu mỗi tab cần nháp riêng, tránh singleton toàn cục. Ưu tiên state có key theo ID bản ghi, hoặc giữ ở mức trang để một tab không ghi đè tab khác.
Chọn phương án đơn giản nhất mà phù hợp.
Bắt đầu cục bộ. Chỉ nâng cấp khi cảm thấy đau thật sự: truyền props quá nhiều, logic lặp, hoặc reset khó tái tạo.
Xác nhận nhu cầu gỡ lỗi.
Nếu bạn cần một view rõ ràng, có thể inspect thay đổi qua các màn hình, Pinia với actions và inspect trong DevTools sẽ cứu bạn rất nhiều thời gian. Nếu state ngắn hạn và rõ ràng, state cục bộ dễ đọc hơn.
State cục bộ là mặc định khi dữ liệu chỉ quan trọng cho một component trên một trang. Dễ dàng bỏ qua và xây store thừa mà bạn sẽ bảo trì hàng tháng.
Phù hợp rõ ràng là một bảng đơn với bộ lọc của chính nó. Nếu bộ lọc chỉ ảnh hưởng bảng đó (ví dụ danh sách Users) và chẳng có gì khác phụ thuộc, giữ chúng làm ref trong component bảng. Tương tự với UI nhỏ như modal mở/đóng, hàng đang chỉnh sửa, và các mục được chọn.
Cố gắng không lưu những gì có thể tính. Badge “Active filters (3)” nên được tính từ giá trị filter hiện tại. Nhãn sắp xếp, tóm tắt định dạng, và flag “có thể lưu” cũng tốt hơn khi làm bằng computed vì chúng tự đồng bộ.
Quy tắc đặt lại quan trọng hơn công cụ bạn chọn. Quyết định cái gì bị xóa khi đổi route (thường là mọi thứ) và cái gì giữ khi người dùng chuyển view trong cùng một trang (có thể giữ bộ lọc nhưng xóa lựa chọn tạm để tránh bulk actions bất ngờ).
State cục bộ thường đủ khi:
Giới hạn chính là chiều sâu. Khi bạn bắt đầu luồn cùng một state qua nhiều component lồng nhau, state cục bộ thành prop drilling, và đó thường là tín hiệu chuyển sang provide/inject hoặc store.
provide/inject nằm giữa state cục bộ và store đầy đủ. Một parent “provide” giá trị cho tất cả con nó, và các component con “inject” mà không cần prop drilling. Trong admin panel, nó phù hợp khi state thuộc về một màn hình hoặc khu vực tính năng, không phải toàn app.
Mẫu phổ biến là một page shell sở hữu state trong khi các component nhỏ tiêu thụ nó: thanh bộ lọc, bảng, toolbar bulk actions, drawer chi tiết, và banner “thay đổi chưa lưu”. Shell có thể provide một bề mặt reactive nhỏ như object filters, draftStatus (dirty, saving, error), và vài flag chỉ đọc (ví dụ isReadOnly dựa trên quyền).
Nếu bạn provide mọi thứ, bạn cơ bản tái tạo một store với ít cấu trúc hơn. Chỉ provide những gì vài child thực sự cần. Bộ lọc là ví dụ kinh điển: khi bảng, chips, hành động xuất và phân trang phải đồng bộ, tốt hơn là chia sẻ một nguồn chân lý hơn là tung hứng props và events.
Rủi ro lớn nhất là phụ thuộc ẩn: một child “vô tư hoạt động” vì có cái gì đó cấp trên provide, và sau này khó biết cập nhật đến từ đâu. Để giữ code dễ đọc và test, đặt tên injection rõ ràng (thường bằng constant hoặc Symbol). Cũng ưu tiên provide actions, không chỉ đối tượng mutable. Một API nhỏ như setFilter, markDirty, và resetDraft làm rõ quyền sở hữu và thay đổi cho phép.
Pinia nổi bật khi cùng một state phải nhất quán giữa các route và component. Trong admin panel, thường là user hiện tại, quyền của họ, workspace/organization đang chọn, và cài đặt app. Việc mỗi màn hình tự triển khai lại sẽ rất mệt.
Một store giúp vì bạn có một nơi để đọc và cập nhật state dùng chung. Thay vì truyền props qua nhiều lớp, import store nơi cần. Khi bạn chuyển từ danh sách sang trang chi tiết, phần còn lại của UI vẫn phản ứng với cùng workspace, quyền và cài đặt.
Pinia đẩy một cấu trúc đơn giản: state cho giá trị thô, getters cho giá trị dẫn xuất, và actions cho cập nhật. Trong UI admin, cấu trúc đó ngăn các “sửa nhanh” biến thành mutation rải rác.
Nếu “canEditUsers” phụ thuộc vào role hiện tại cộng feature flag, đặt quy tắc trong getter. Nếu chuyển org cần xóa cache chọn và load lại navigation, đặt sequence đó trong action. Bạn sẽ có ít watcher bí ẩn hơn và ít khoảnh khắc “tại sao cái này thay đổi?”.
Pinia cũng hoạt động tốt với Vue DevTools. Khi có bug, dễ inspect state store và thấy action nào đã chạy hơn là lần theo các object reactive rải rác trong component.
Store toàn cục ban đầu cảm giác gọn, nhưng rồi thành hộp rác. Ứng viên tốt cho Pinia là các mối quan tâm thật sự dùng chung như user identity và permissions, workspace đã chọn, feature flags, và dữ liệu tham chiếu dùng khắp nơi.
Mối quan tâm chỉ ở trang (như input tạm của một form) nên giữ cục bộ trừ khi nhiều route thực sự cần.
Hãy tưởng tượng trang Orders: một bảng, bộ lọc (status, khoảng ngày, customer), phân trang, và panel bên xem trước order chọn. Rất nhanh chóng sẽ lộn xộn vì dễ bị cám dỗ đưa mọi filter và cài đặt bảng vào store toàn cục.
Cách đơn giản là quyết định cái gì nên được nhớ và ở đâu:
Từ đó, triển khai thường theo:
Nếu không ai mong settings tồn tại qua điều hướng, giữ filters, sort, page, và pageSize trong component Orders, và trang đó chịu trách nhiệm fetch. Nếu toolbar, bảng và preview panel đều cần cùng mô hình và prop drilling bắt đầu phiền, chuyển mô hình danh sách lên page shell và chia sẻ qua provide/inject. Nếu bạn muốn danh sách cảm giác “dính” qua các route (mở một order, nhảy đi, quay lại cùng bộ lọc và selection), Pinia là lựa chọn tốt.
Quy tắc thực tế: bắt đầu cục bộ, chuyển lên provide/inject khi vài child cần cùng mô hình, và chỉ dùng Pinia khi bạn thực sự cần tồn tại qua route.
Hãy tưởng tượng một support agent chỉnh sửa hồ sơ khách hàng: thông tin liên hệ, thanh toán, và ghi chú nội bộ. Họ bị gián đoạn, đổi màn hình, rồi quay lại. Nếu form quên công việc họ hoặc lưu dữ liệu nửa vời, lòng tin mất.
Với nháp, tách ba thứ: bản ghi đã lưu gần nhất, chỉnh sửa tạm của người dùng, và UI-only state như lỗi validate.
Nếu màn chỉnh sửa tự chứa, state cục bộ thường an toàn nhất. Giữ một bản draft sao chép từ bản ghi, theo dõi isDirty (hoặc map dirty theo trường), và lưu lỗi bên cạnh control form.
Luồng đơn giản: load bản ghi, clone thành draft, chỉnh sửa draft, và chỉ gửi yêu cầu save khi người dùng bấm Save. Cancel hủy draft và load lại.
Form admin thường chia tab hoặc panel (Profile, Addresses, Permissions). Với provide/inject, bạn giữ một model draft và expose API nhỏ như updateField(), resetDraft(), và validateSection(). Mỗi section đọc và ghi cùng một draft mà không cần truyền props qua nhiều lớp.
Pinia hữu ích khi nháp phải tồn tại qua điều hướng hoặc được nhìn thấy ngoài trang edit. Mẫu phổ biến là draftsById[customerId], vậy mỗi bản ghi có nháp riêng. Điều này cũng hỗ trợ khi người dùng mở nhiều màn chỉnh sửa.
Bug về nháp thường từ vài sai lầm: tạo nháp trước khi bản ghi được load, ghi đè nháp dirty khi refetch, quên xóa lỗi khi cancel, hoặc dùng một key chung khiến nháp ghi đè nhau. Nếu bạn đặt quy tắc rõ ràng (khi tạo, ghi đè, hủy, persist và thay thế sau save), hầu hết lỗi sẽ biến mất.
Nếu bạn xây admin với AppMaster, tách nháp và bản ghi đã lưu vẫn đúng: giữ nháp trên client và coi backend là nguồn chân lý chỉ sau khi Save thành công.
Chỉnh sửa đa tab là nơi admin panel thường vỡ. Người dùng mở Customer A, sau đó Customer B, chuyển qua lại, và mong mỗi tab nhớ chỉnh sửa chưa lưu của riêng nó.
Sửa là mô hình mỗi tab như một bundle trạng thái riêng, không phải một nháp chung. Mỗi tab cần ít nhất một key duy nhất (thường dựa trên ID bản ghi), dữ liệu draft, trạng thái (clean, dirty, saving), và lỗi trường.
Nếu tabs nằm trong một màn, cách cục bộ hiệu quả: giữ danh sách tab và nháp do component trang sở hữu. Mỗi panel editor chỉ đọc và ghi bundle riêng. Khi đóng tab, xóa bundle tương ứng là xong. Cách này cô lập và dễ suy luận.
Dù state ở đâu, cấu trúc thường giống nhau:
customerId, draft, status, và errors)activeTabKeyopenTab(id), updateDraft(key, patch), saveTab(key), và closeTab(key)Pinia là lựa chọn khi tabs phải tồn tại qua điều hướng (nhảy sang Orders rồi quay lại) hoặc khi nhiều màn cần mở và focus tabs. Khi đó, một store “tab manager” nhỏ giữ hành vi nhất quán khắp app.
Va chạm chính cần tránh là một biến global duy nhất như currentDraft. Nó hoạt động cho tới khi tab thứ hai mở, rồi chỉnh sửa ghi đè nhau, lỗi validate hiện ở chỗ sai, và Save cập nhật bản ghi nhầm. Khi mỗi tab có bundle riêng, va chạm phần lớn biến mất theo thiết kế.
Hầu hết bug admin không phải “bug Vue”. Chúng là bug về state: dữ liệu sống ở chỗ sai, hai phần màn hình không đồng ý, hoặc state cũ lặng lẽ tồn tại.
Các pattern thường gặp:
Đặt mọi thứ vào Pinia theo mặc định khiến quyền sở hữu mơ hồ. Store toàn cục lúc đầu gọn, nhưng sớm muộn mọi trang đọc và ghi cùng object, và cleanup trở thành đoán mò.
Dùng provide/inject không có hợp đồng rõ ràng tạo phụ thuộc ẩn. Nếu một child inject filters nhưng không rõ ai provide và hành động nào được phép thay đổi, bạn sẽ có cập nhật bất ngờ khi child khác bắt đầu mutate cùng object.
Trộn server state và UI state trong cùng store gây ghi đè vô tình. Bản ghi fetch khác với “drawer đang mở?”, “tab hiện tại”, hoặc “trường dirty”. Khi sống cùng nhau, refetch có thể đè UI, hoặc thay đổi UI có thể mutate cache dữ liệu.
Bỏ qua cleanup lifecycle cho phép state rò rỉ. Bộ lọc từ view này ảnh hưởng view khác, và nháp còn lại sau khi rời trang. Lần kế tiếp ai đó mở bản ghi khác, họ thấy lựa chọn cũ và nghĩ app hỏng.
Key nháp kém là kẻ hủy lòng tin thầm lặng. Nếu bạn lưu nháp dưới key như draft:editUser, chỉnh User A rồi User B ghi đè cùng một draft.
Một quy tắc đơn giản ngăn hầu hết: giữ state càng gần nơi dùng càng tốt, và chỉ nâng khi hai phần độc lập thật sự cần chia sẻ. Khi chia sẻ, định nghĩa quyền sở hữu (ai được thay đổi) và identity (key thế nào) rõ ràng.
Câu hỏi hữu ích nhất: ai sở hữu state này? Nếu bạn không thể nói trong một câu, state có lẽ đang làm quá nhiều và nên tách ra.
Dùng các kiểm tra này như lọc nhanh:
provide/inject thường phù hợp.Tương ứng công cụ, nói ngắn gọn:
Nếu state sinh và chết trong một component (như flag dropdown mở/đóng), giữ cục bộ. Nếu vài component trên cùng một màn cần ngữ cảnh chung (filter bar + table + summary), provide/inject giữ chia sẻ mà không thành global. Nếu state phải chia sẻ giữa màn, tồn tại qua điều hướng, hoặc cần cập nhật có thể gỡ lỗi, dùng Pinia và key theo ID khi nháp tham gia.
Nếu bạn đang xây UI admin Vue 3 (bao gồm app sinh ra bởi công cụ như AppMaster), checklist này giúp tránh bỏ mọi thứ vào store quá sớm.
Cách an toàn nhất để cải thiện quản lý state trong admin panel là phát triển từng bước nhỏ, chậm. Bắt đầu với state cục bộ cho bất cứ thứ gì ở bên trong một trang. Khi thấy tái sử dụng thực sự (logic lặp, component thứ ba cần cùng state), nâng lên một cấp. Chỉ khi đó xem tới store dùng chung.
Một lộ trình hiệu quả cho hầu hết nhóm:
provide/inject khi vài component trên cùng trang cần context chung.Quy tắc reset nghe nhỏ nhưng ngăn hầu hết khoảnh khắc “tại sao nó thay đổi?”. Quyết định, ví dụ, điều gì xảy ra với nháp khi mở một bản ghi khác rồi quay lại: restore, warn, hay reset. Sau đó giữ hành vi đó đồng nhất.
Nếu bạn giới thiệu store, giữ nó có hình dạng theo tính năng. Store nháp nên xử lý tạo, phục hồi, và xóa nháp, nhưng không nên ôm luôn lọc bảng hay flag layout UI.
Nếu bạn muốn prototype nhanh một admin panel, AppMaster (appmaster.io) có thể sinh app Vue3 cùng backend và business logic, và bạn vẫn có thể tinh chỉnh mã sinh ra nơi cần xử lý state tùy chỉnh. Bước thực tế tiếp theo là xây một màn end-to-end (ví dụ một form edit với khôi phục nháp) và xem cái nào thật sự cần Pinia còn cái nào giữ cục bộ.
When should I keep state local in a Vue 3 admin panel?Sử dụng state cục bộ khi dữ liệu chỉ ảnh hưởng tới một component và có thể được đặt lại khi component đó unmount. Ví dụ thường gặp: trạng thái mở/đóng dialog, các hàng được chọn trong một bảng duy nhất, hoặc một phần của form không được tái sử dụng ở nơi khác.
When is `provide/inject` better than a store?Dùng provide/inject khi nhiều component trên cùng một trang cần một nguồn dữ liệu chung và việc truyền props trở nên rắc rối. Hãy cung cấp thật ít thứ cần thiết để trang dễ hiểu và dễ bảo trì.
What’s the clearest sign I should use Pinia?Dùng Pinia khi state cần được chia sẻ giữa các route, tồn tại sau điều hướng, hoặc cần dễ quan sát và gỡ lỗi ở một chỗ. Các ví dụ phổ biến: workspace hiện tại, quyền truy cập, feature flags, và các bộ quản lý đa màn hình như drafts hoặc tabs.
How do I classify state before choosing a tool?Bắt đầu bằng việc đặt tên loại state (UI, server, form, cross-screen), rồi xác định phạm vi (một component, một trang, nhiều route), thời gian sống (đặt lại khi unmount, tồn tại sau điều hướng, tồn tại sau reload) và cạnh tranh (chỉ một editor hay nhiều tab). Thông thường công cụ sẽ theo sau từ những nhãn này.
Should table filters live in the URL, local state, or Pinia?Nếu người dùng mong muốn chia sẻ hoặc khôi phục chế độ xem, đưa bộ lọc và phân trang vào query params để chúng tồn tại sau reload và có thể sao chép. Nếu mong muốn là “quay lại danh sách như đã để”, lưu mô hình danh sách trong Pinia; nếu không thì giữ trên trang.
What’s the safest way to handle unsaved edits in big admin forms?Tách rõ bản ghi đã lưu cuối cùng khỏi chỉnh sửa tạm thời của người dùng, và chỉ ghi lại khi người dùng bấm Save. Theo dõi trạng thái dirty rõ ràng và quyết định hành vi khi điều hướng (cảnh báo, tự động lưu, hoặc giữ nháp có thể khôi phục) để tránh mất dữ liệu.
How do I avoid multi-tab editing collisions?Cung cấp cho mỗi bộ editor đang mở một bundle trạng thái riêng, key theo ID bản ghi (và đôi khi key tab). Tránh một currentDraft toàn cục vì tab thứ hai sẽ ghi đè tab thứ nhất. Điều này ngăn xung đột chỉnh sửa và lỗi validate xuất hiện nhầm chỗ.
Should drafts be local, provided, or stored in Pinia?Nếu cả flow chỉnh sửa nằm trong một route, provide/inject do trang sở hữu có thể ổn. Nếu nháp phải tồn tại sau điều hướng hoặc cần truy cập từ ngoài màn hình chỉnh sửa, Pinia với cấu trúc như draftsById[recordId] thường là giải pháp đơn giản và ổn định hơn.
What state should be computed instead of stored?Không lưu những thứ có thể tính được. Dùng computed cho các badge, tóm tắt và flag “có thể lưu” để chúng luôn đồng bộ với trạng thái hiện tại.
What are the most common state mistakes in admin panels?Đặt mọi thứ vào Pinia mặc định, trộn server state với toggles UI, và bỏ qua cleanup khi điều hướng là những nguyên nhân phổ biến nhất gây hành vi khó hiểu. Cũng cần tránh dùng một key nháp chung cho nhiều bản ghi.
21 thg 1, 2026
8 phút
20 thg 1, 20268 phút
20 thg 1, 20268 phútThử nghiệm với AppMaster với gói miễn phí.
Khi bạn sẵn sàng, bạn có thể chọn đăng ký phù hợp.
