Bài này nói về state React/Next mức senior cho phỏng vấn, map từ Vuex/Pinia. Nó đi qua tầng nào chịu trách nhiệm một fact (URL, cookie/RSC, Query, Context, Zustand), vì sao list server không thuộc Redux, luồng một chiều khác store mutable của Vue, và những bug production người phỏng vấn hay tái sử dụng. Dành cho engineer đã ship Pinia, giờ cần biết đặt state ở đâu, không phải tour thư viện.

Đọc 22.1 và 22.4 trước (các tầng, rồi luồng quyết định). Người phỏng vấn xoáy “Redux, Context, hay Query?” nhiều hơn cú pháp slice. Rồi 22.5 cho queryKey / invalidation, 22.6 cho App Router, 22.7 cho bản map Pinia, 22.8 cho snippet họ đưa. Nêu rõ owner của fact trong một câu trước khi nêu tên thư viện.

Tóm tắt: Đặt mỗi fact vào tầng hẹp nhất vẫn share đúng: theo nguồn sự thật và vòng đời, không phải “global khác local”. URL, cookie/RSC, Query, Context, và Zustand là các owner khác nhau. Một fact, một owner. Analog Vue: ref / route.query / useCookie / useAsyncData / Pinia.

Vì sao quan trọng: “Redux, Context, hay Query?” cho bảng product, giỏ khách, user hiện tại, và theme toggle là phần khởi động. Đổ hết Pinia vào Redux là miss của senior Vue. Nếu hai tầng cùng nhận một field, bạn đã có bug.

1. Cách hoạt động: UI local (useState) chết cùng component. State lifted sống ở parent gần nhất mà hai sibling share. Context là dependency injection ít đổi (theme, locale, QueryClient). Store client giữ một graph chẳng đáng nằm trên URL, cũng không phải data server.
2. URL (searchParams) thắng filter, tab, pagination: share được và nút back. Cookie / session server thắng login. RSC + TanStack Query thắng list server. Thứ tự Next: URL và cookie thắng store client khi cần reload, share, và tin cậy. Xem 22.6.
3. Hầu hết màn hình là URL + Query + vài useState. Store xuất hiện khi workflow phía client là một graph (giỏ khách, editor nhiều bước). Analog Vue: cũng đừng đổ route.query vào Pinia.

// Bốn fact, bốn owner: nói “Redux” cho cả bốn là miss
export function Catalog({ searchParams }: { searchParams: { q?: string } }) {
  const q = searchParams.q ?? '' // URL chịu trách nhiệm filter
  const { data: items } = useQuery({ queryKey: ['items', q], queryFn: () => api.items(q) })
  const [open, setOpen] = useState(false) // UI local: modal
  const qty = useCart((s) => s.items.length) // graph client: giỏ khách
  return (
    <>
      <p>Cart {qty}</p>
      <button onClick={() => setOpen(true)}>Filters</button>
      {open && <FilterSheet q={q} />}
      <ul>{items?.map((it) => <li key={it.id}>{it.title}</li>)}</ul>
    </>
  )
}
// User hiện tại: cookie httpOnly + RSC. Theme: Context. Đừng gộp chúng ở đây.

Điều gì xảy ra: Filter sống sau reload và share vì nó nằm trên URL. List là Query, key theo q. Modal là local. Giỏ là store client vì graph giỏ khách không phải list server. Login không nằm trong file này: nó là cookie.

Lỗi hay gặp

• Triệu chứng: filter nằm cả Zustand lẫn URL. Nguyên nhân: hai owner. Cách xử lý: URL thắng; derive UI từ searchParams.
• Triệu chứng: list user trong slice Redux. Nguyên nhân: đổ nguyên Pinia. Cách xử lý: Query / RSC.
• Triệu chứng: user hiện tại trong Context, cập nhật mỗi lần gõ. Nguyên nhân: gộp draft. Cách xử lý: tách ra; session là cookie.
• Triệu chứng: theme trong store giỏ. Nguyên nhân: một túi global. Cách xử lý: Context cho theme.

Tóm tắt: Chọn store client theo team và hình dạng của graph, không bao giờ cho list server. RTK là lối đi sẵn. Zustand là DX kiểu Pinia nếu bạn bắt selector. Jotai là atom khi một store sẽ thành god object. Đừng chạy RTK Query và TanStack Query cùng lúc.

Vì sao quan trọng: “Redux đã chết?” và “store nào cho team 20 người?” muốn một lựa chọn theo quy mô team, không phải Twitter. Họ sẽ đánh rớt nếu list user nằm trong slice. Analog Vue: Vuex khác Pinia khác nhiều ref nhỏ.

1. Cách hoạt động: RTK: configureStore + slice + convention + DevTools. Mặc định cho team 15–40 cần lối đi sẵn, middleware log sự kiện, hoặc RTK Query đã có sẵn.
2. Zustand: create((set, get) => …) + selector hẹp. Mặc định cho solo / product nhỏ nếu bạn viết convention selector. Không selector thì re-render loạn như Context. Jotai: nhiều atom, atom derived, cho editor và graph node.
3. Cùng một feature trong mỗi cái: qty của giỏ. RTK useSelector(s => s.cart.items.length). Zustand useCart(s => s.items.length). Jotai useAtomValue(qtyAtom). Không cái nào fetch catalog. Analog Vue: Vuex / Pinia / nhiều ref: fetch vẫn không nằm trong store.

// Cùng một fact, qty giỏ, ba store. Không cái nào chịu trách nhiệm catalog.
// RTK: const qty = useSelector((s: Root) => s.cart.items.length)
// Zustand
const useCart = create<Cart>((set) => ({
  items: [] as { id: string }[],
  add: (id: string) => set((s) => ({ items: [...s.items, { id }] })),
}))
const qty = useCart((s) => s.items.length) // selector là ràng buộc production
// Jotai
const itemsAtom = atom<{ id: string }[]>([])
const qtyAtom = atom((get) => get(itemsAtom).length)
// Đừng: users[] trong bất kỳ cái nào. Đó là Query.
// Đừng chạy RTK Query và TanStack Query trong cùng app.

Điều gì xảy ra: Qty là lần đọc từ graph phía client. Selector Zustand subscribe items.length, không phải cả store. Jotai derive qty từ atom items. Catalog vắng mặt có chủ đích: đó là 22.5.

Lỗi hay gặp

• Triệu chứng: user trong slice. Nguyên nhân: “đã có Redux”. Cách xử lý: Query. Xem 22.5.
• Triệu chứng: useCart() cả store. Nguyên nhân: thói quen Pinia. Cách xử lý: (s) => s.items.length.
• Triệu chứng: RTK Query kèm TanStack Query. Nguyên nhân: hai lối đi sẵn. Cách xử lý: chọn một.
• Triệu chứng: Jotai cho flag theme. Nguyên nhân: theo mốt. Cách xử lý: Context.

Tóm tắt: RTK, Zustand, và Jotai là luồng UI client. List HTTP rời diagram này sang Query hoặc RSC. Bạn subscribe bằng selector hẹp. useCart() cả store là thrash hạng Context. Pinia của Vue thì mutate; các store này thay một slice (Immer hoặc object mới).

Vì sao quan trọng: “Vẽ luồng data Redux”, rồi “GET list nằm ở đâu, Zustand khác Pinia thế nào, và vì sao useCart() không selector làm cả cây thrash?” Trộn fetch trong set là tự viết lại thunk mà không có cache. Xem React 20.1.4 về bất biến khác mutation của Vue.

1. Cách hoạt động: RTK: UI dispatch → reducer slice cập nhật bất biến (Immer) → thunk / listener / RTK Query cho async → useSelector re-render. Zustand: UI gọi useCart(s => s.add)(id) → set thay một slice → subscriber có slice đã chọn đổi theo Object.is thì re-render.
2. Jotai: setAtom → atom derive tính lại → chỉ component đã subscribe mới re-render. Action nên là cập nhật store thuần hoặc gọi mutation Query. Đừng fetch trong set.
3. Analog Vue: Pinia mutate cart.items.push. Zustand/RTK thay array. Cùng kết quả user thấy; chuyện identity thì khác. Server Component không dispatch vào Redux được. Trên server không có store phía client.

// Kỷ luật selector là ràng buộc production.
const qty = useCart((s) => s.items.length) // Object.is trên một số
const add = useCart((s) => s.add)
// Subscribe cả store = thrash (mỗi lần gõ nếu draft nằm ở đây)
// const cart = useCart()

add('sku-1')
// set Zustand phải thay: set({ items }) sau mutate tại chỗ thì identity array không đổi.
// const items = get().items; items.push(row); set({ items }) // ❌ cùng reference
// set((s) => ({ items: [...s.items, row] })) // ✅
// List HTTP GET không xuất hiện trong file này. Đó là Query.

Điều gì xảy ra: qty chỉ re-render khi length đổi. add lấy action với reference ổn định. Mutate items tại chỗ rồi set({ items }) giữ cùng identity array, nên subscriber chọn items có thể miss lần cập nhật. List GET vắng mặt có chủ đích.

Lỗi hay gặp

• Triệu chứng: cây thrash lúc thêm vào giỏ. Nguyên nhân: useCart() cả store. Cách xử lý: selector.
• Triệu chứng: UI cũ sau items.push. Nguyên nhân: cùng identity array. Cách xử lý: thay array.
• Triệu chứng: fetch trong set của Zustand. Nguyên nhân: tự viết lại thunk. Cách xử lý: mutation Query.
• Triệu chứng: dispatch từ Server Component. Nguyên nhân: không có client. Cách xử lý: Client island hoặc Action.

Tóm tắt: Đi một luồng quyết định, đừng chọn thư viện yêu thích. Ephemeral → useState. Share được → URL. Identity tin cậy → cookie. Remote/cũ → Query hoặc RSC. DI ít đổi → Context. Đồ thị client tần suất cao → store với selector. Đẩy state xuống đến khi sibling cần.

Vì sao quan trọng: “Khi nào Context đủ?” và “sao không một React Context cho cả app?” đi kèm giỏ trong Context. Họ muốn bạn chuyển giỏ và nêu rõ cái không chuyển (catalog item ở lại Query). Xem Context khác provide.

1. Cách hoạt động: 1. Một component / cây ngắn, ephemeral → useState / useReducer. 2. Share được / nút Back / bookmark → URL. 3. Identity tin cậy / session → cookie + server.
2. 4. Data remote có thể cũ → TanStack Query / SWR (hoặc RSC cho document). 5. DI ít đổi (theme, locale, flag, QueryClient) → Context, tách provider. 6. Workflow client tần suất cao hoặc phức tạp → Zustand / RTK / Jotai với selector.
3. Đẩy state xuống đến khi sibling cần. Đừng lift cho tiện. Nếu shell sáng khi bạn gõ, tầng sai. Analog Vue: provide thì track; Context thì broadcast. Tách ra. Catalog không chuyển khi giỏ chuyển.

// Giỏ trong Context là snippet họ đưa. Catalog không chuyển.
// ❌ <Shop.Provider value={{ cart, setCart, items, setItems, draft }}> 
// ✅ catalog ở lại Query; giỏ chuyển sang Zustand; draft ở lại local
export function Shop() {
  const { data: items } = useQuery({ queryKey: ['catalog'], queryFn: api.catalog })
  const add = useCart((s) => s.add)
  const [draft, setDraft] = useState('')
  return (
    <>
      <input value={draft} onChange={(e) => setDraft(e.target.value)} />
      <ul>{items?.map((it) => (
        <li key={it.id}><button onClick={() => add(it.id)}>{it.title}</button></li>
      ))}</ul>
    </>
  )
}

Điều gì xảy ra: Gõ draft thì re-render Shop, không phải cả cây của một Context quá nặng. Thêm vào giỏ thì cập nhật subscriber Zustand. Catalog ở lại Query. Filter lẽ ra nằm ở searchParams, không phải setItems.

Lỗi hay gặp

• Triệu chứng: shell sáng khi bạn gõ. Nguyên nhân: draft trong Context / store. Cách xử lý: useState local.
• Triệu chứng: một Context cho cả app. Nguyên nhân: cho tiện. Cách xử lý: tách provider; chuyển slice nóng.
• Triệu chứng: catalog copy vào Zustand “để giỏ đọc được”. Nguyên nhân: thêm một owner. Cách xử lý: Query trong component.
• Triệu chứng: memo trên consumer Context “để chặn rerender”. Nguyên nhân: value mới mỗi render. Cách xử lý: tách hoặc store.

Tóm tắt: Server state là async, stale, gắn key, và share được. TanStack Query / SWR đã lo contract đó. queryKey là identity của cache (gồm cả filter). Sau POST: invalidateQueries. staleTime là độ tươi; gcTime là data không dùng còn nằm trong memory bao lâu (trước đây cacheTime). Đừng copy data của Query vào Zustand.

Vì sao quan trọng: “Sao không useEffect + useState cho list user? Sao không Redux?” Họ xem queryKey có gồm filter không, và bạn invalidate gì sau POST. Trên Next, ghép revalidateTag khi cây RSC cũng hiện data đó. Xem Server Actions.

1. Cách hoạt động: useQuery({ queryKey: ['users', filter], queryFn }) là một ô cache cho mỗi filter. staleTime (ví dụ 30_000) nghĩa là “đừng refetch trong 30s”. gcTime nghĩa là “quên ô này khi không còn observer”. POST dùng useMutation rồi invalidateQueries({ queryKey: ['users'] }) (khớp prefix).
2. Trong Next: RSC lo first paint của document; Query lo tương tác client trên data đó (pagination không được làm rơi shell, polling, hàng optimistic). Sau khi ghi, invalidateQueries và revalidateTag nếu cả hai cây đều hiện. Đừng chạy SWR và Query cùng lúc.
3. Tương đương Vue: useAsyncData / useFetch kèm refreshNuxtData. Chỉ khi có lý do mạnh mới để list API trong store: replication offline-first, CRDT cộng tác. Lúc đó bạn không phải cache. Query đã abort sẵn; effect tự viết phải dùng AbortController.

// queryKey là identity của cache: gồm cả filter. Invalidation là contract lúc ghi.
const filter = searchParams.get('role') ?? 'all'
const { data } = useQuery({
  queryKey: ['users', filter],
  queryFn: () => api.users(filter),
  staleTime: 30_000, // tươi 30s; gcTime (trước đây cacheTime) là eviction
})
const qc = useQueryClient()
const { mutate } = useMutation({
  mutationFn: createUser,
  onSuccess: () => qc.invalidateQueries({ queryKey: ['users'] }),
})
// Đừng: setUsers trong Zustand lúc onSuccess. Đừng: queryKey: ['users'] cho mọi filter.
// Next + RSC: cũng revalidateTag('users') từ Server Action.

Điều gì xảy ra: Role admin và role all là hai ô cache. Tạo user thì invalidate mọi prefix users, nên cả hai ô đều refetch. Copy data vào Zustand sẽ tạo owner thứ ba, đã stale. staleTime tránh refetch lúc remount trong 30s; gcTime là cơ chế khác.

Lỗi hay gặp

• Triệu chứng: filter A hiện hàng filter B. Nguyên nhân: queryKey: ['users']. Cách xử lý: gồm filter.
• Triệu chứng: list stale sau POST. Nguyên nhân: không invalidateQueries. Cách xử lý: invalidate prefix; trên Next cũng revalidateTag.
• Triệu chứng: Zustand users kèm Query users. Nguyên nhân: copy data. Cách xử lý: xóa slice.
• Triệu chứng: race trên fetch useEffect tự viết. Nguyên nhân: không abort. Cách xử lý: Query, hoặc AbortController.

Tóm tắt: App Router chuyển nguồn sự thật mặc định sang server: RSC + cookie + URL, rồi island Client nhỏ nhất. Server Component không có useState cũng không có Zustand. Persist Zustand đọc localStorage trong create() thì lệch SSR. Sau mutation: revalidateTag và/hoặc invalidateQueries, thường là cả hai.

Vì sao quan trọng: “App Router đổi state management thế nào?” User hiện tại nằm ở đâu, và cái gì gãy nếu persist Zustand đọc localStorage trong create() lúc SSR? Xem App Router và middleware.

1. Cách hoạt động: Server Component fetch và render data server. Island use client giữ state tương tác: island nhỏ nhất cần hook. URL (searchParams) cho UI share được. Cookie / session server cho auth. Zustand không đáng tin làm nguồn sự thật login.
2. Đưa DTO serialise được xuyên ranh giới RSC, không phải row ORM hay hàm (21.12). Sau mutation: revalidatePath / revalidateTag cho cây server, invalidateQueries cho cache client, thường cả hai nếu cả hai cây hiện data.
3. Tương đương Nuxt: useAsyncData + useCookie + refreshNuxtData + island client nhỏ. useState của Nuxt được share lúc SSR; Next thường không clone kiểu đó: cookie + RSC + island nhỏ. Persist/hydrate thì cẩn thận, hoặc bỏ.

// app/cart/page.tsx: Server Component. Không useState. Không Zustand ở đây.
export default async function CartPage() {
  const session = await getSession() // cookie: nguồn sự thật login
  if (!session) redirect('/login')
  return <CartIsland userId={session.id} /> // chỉ id serialise được
}
// cart-island.tsx: use client
// persist() đọc localStorage trong create() cũng chạy trên server.
// HTML là [] ; first paint phía client có items → lệch hydration.
// Cách xử lý: cùng default hai phía, rồi useEffect fill / skipHydration.
// Sau Action addItem: revalidateTag('cart') và qc.invalidateQueries({ queryKey: ['cart'] }).

Điều gì xảy ra: Nguồn sự thật login không bao giờ vào Zustand. Island nhận một id, không phải hàm. Persist trong create() sẽ vẽ giỏ khách trên server và giỏ đầy trên client. Một lần ghi phải refresh cả hai cây nếu Query cũng hiện giỏ.

Lỗi hay gặp

• Triệu chứng: HTML [] rồi giỏ đầy. Nguyên nhân: persist đọc localStorage trong create(). Cách xử lý: cùng default, rồi useEffect fill.
• Triệu chứng: RSC đã login, island vẫn logged-out. Nguyên nhân: lấy Zustand làm nguồn sự thật login. Cách xử lý: cookie + truyền id.
• Triệu chứng: cả cây dynamic. Nguyên nhân: cookies() trong layout gốc. Cách xử lý: đưa lần đọc xuống dưới.
• Triệu chứng: Client vẫn cũ sau Action. Nguyên nhân: chỉ revalidateTag. Cách xử lý: thêm invalidateQueries.

Tóm tắt: Map thói quen, rồi bỏ fetch. Mutation vs action của Vuex tương ứng reducer vs thunk của RTK. “Cứ gọi action” của Pinia là Zustand. fetchOrders trong Pinia thành useQuery, không phải useOrderStore với loading và error. Port module Vuex 1:1 là cái bẫy.

Vì sao quan trọng: “Mình biết Pinia, nhìn đâu bên React?” Họ muốn bản map thói quen, rồi xem bạn bỏ những phần Query/RSC đã thay. Dựng lại state.loading / state.error cho mỗi list chính là isPending / error của Query.

1. Cách hoạt động: Cột trái là từ Vue bạn đã biết. Trả lời bằng cột phải, rồi nêu cái bẫy ở hàng đó. Đừng đọc cả bảng.
2. Port theo tầng mất một sprint: URL cho filter, Query cho list, flag UI còn lại để trong Zustand. Grep fetch( trong file store sau migration: mỗi hit là một hàng bạn chưa bỏ. Plugin persist từ Vuex/Pinia nguy hiểm trên Next cho đến khi bạn có câu chuyện hydration (22.6).

// Thói quen Pinia: fetchOrders async trong store, kèm flag loading / error.
// Port React: bỏ fetch. Phần còn lại là flag UI thôi.
export function useOrders(status: string) {
  return useQuery({
    queryKey: ['orders', status],
    queryFn: () => api.orders(status),
  }) // isPending / error sống ở đây, không phải useOrderStore
}
const useOrderUi = create(() => ({ drawerOpen: false }))
// Grep fetch( trong file store sau migration. Mỗi hit là hàng bạn chưa bỏ.
// Đừng port plugin persist sang Next cho đến khi 22.6 có câu chuyện hydration.

Điều gì xảy ra: useOrders là Query. Store Zustand nhỏ chỉ có drawerOpen. Loading và error không chuyển sang. Đó là chỗ bỏ fetch. useOrderStore 1:1 sẽ giữ nguyên bug cũ.

Lỗi hay gặp

• Triệu chứng: useOrderStore với loading và error. Nguyên nhân: port Pinia 1:1. Cách xử lý: useQuery.
• Triệu chứng: fetch( vẫn trong file store. Nguyên nhân: thói quen chưa bỏ. Cách xử lý: grep, rồi Query.
• Triệu chứng: copy plugin persist sang Next. Nguyên nhân: quen tay plugin SSR của Nuxt. Cách xử lý: 22.6.
• Triệu chứng: đọc cả sáu hàng. Nguyên nhân: coi sheet là câu trả lời. Cách xử lý: một hàng, rồi topic.

Tóm tắt: Bẫy là vi phạm tầng. Nêu rõ tầng, lỗi, và cách bạn đo. Context mỗi lần gõ, user trong Redux, fetch bằng useEffect, filter ở hai chỗ, persist lúc SSR, auth trong localStorage, let cache mức module trên server.

Vì sao quan trọng: Họ đưa một snippet rồi hỏi “bạn đã phá gì?” Câu senior không phải “Mình sẽ dùng Zustand”. Đó là vi phạm tầng, lỗi user nhìn thấy, và Profiler / payload / overlay hydration bạn sẽ mở. Tầng sai đắt hơn thiếu một useCallback. Xem checklist React.

1. Cách hoạt động: Mở rộng từ snippet họ đưa. Mọi thứ trong Context → tách provider hoặc store với selector. Mọi thứ trong Redux/Zustand → list thuộc Query/RSC. useEffect fetch không abort → race, Strict Mode chạy hai lần; ưu tiên Query.
2. Store mirror URL → URL thắng cho filter. Hydration → cùng default hai phía, rồi useEffect fill; cookie theme; suppressHydrationWarning chỉ trên một node clock đã biết. Auth trong localStorage → cookie/session thắng. let cache mức module trên server sống lâu sẽ leak sang user khác.
3. UI optimistic không rollback là lời nói dối mà lần refresh sau sẽ hủy. Đặt sáu fact: filter product, user hiện tại, giỏ, hàng toast, bài CMS, presence websocket: sáu tầng. Tương đương Vue: cùng loại vi phạm nằm ở chỗ nhét hết vào Pinia và window.__NUXT__.

// 1. Persist lúc SSR khác client: HTML là [], first paint có items.
const useCart = create(persist(() => ({ items: [] as Item[] }), { name: 'cart' }))
// 2. Gõ draft thì mọi consumer của user cũng re-render.
// <UserContext.Provider value={{ user, setUser, draft, setDraft }}>
// 3. Cache module phía server leak sang user khác.
let cache: User | undefined // ❌ process Node sống lâu
export function getCachedUser() { return cache }
// Cách xử lý: skipHydration / cùng default rồi fill; tách Context; cache theo request.
// Đo: overlay hydration; Profiler lúc gõ; tìm user B trong body RSC.

Điều gì xảy ra: Ba snippet, ba vi phạm tầng. Persist trong create() lệch HTML. Context quá nặng broadcast mọi lần gõ. let module trên Node là user B thấy user A. Mỗi cái có cách đo: overlay, Profiler, tìm payload.

Lỗi hay gặp

• Triệu chứng: trả lời bằng tên thư viện. Nguyên nhân: bỏ qua layer. Cách xử lý: layer, lỗi, cách đo.
• Triệu chứng: UI optimistic không rollback. Nguyên nhân: paint khi chưa có server. Cách xử lý: onError restore hoặc bỏ lần paint.
• Triệu chứng: đổ lỗi React vì persist lệch. Nguyên nhân: localStorage trong create(). Cách xử lý: 22.6.
• Triệu chứng: “bọn mình đã memo”. Nguyên nhân: sai layer. Cách xử lý: Profiler, rồi chuyển fact.