Bài này nói về state Vue ở góc nhìn senior cho phỏng vấn: Pinia là mặc định, Vuex là thứ bạn vẫn phải nói khi gặp app legacy, và câu hỏi cốt lõi là một mảnh state nằm ở đâu: component, URL, Pinia, hay cache phía server. Dành cho engineer đã biết defineStore, giờ cần ra quyết định dưới SSR, ranh giới store, và invalidation.

Đọc 7.1–7.3 trước (Pinia vs Vuex, luồng, global vs local vs URL). Người phỏng vấn xoáy ranh giới store, SSR theo từng request, và “Pinia không phải REST cache” nhiều hơn commit vs dispatch. Rồi 7.4–7.5 chỉ khi role vẫn còn Vuex, và 7.6–7.7 cho hydration và invalidation. Bản React là Quản lý state (React). Với mỗi topic, nêu rõ ràng buộc, lỗi bạn đã gặp, và cách bạn chứng minh fix.

Tóm tắt: Pinia là store chính thức của Vue 3: nhiều store nhỏ, TypeScript suy luận được, không mutation. Vuex là một store có namespace, bạn vẫn phải nói được khi gặp app legacy.

Vì sao quan trọng: “Vì sao Pinia?” chỉ là câu khởi động. Họ muốn thứ tự migrate, một instance SSR theo từng request, và bạn có copy god object Vuex (một store giữ mọi field) vào useMainStore hay không.

1. Cách hoạt động: Vuex là một store gốc với module có namespace. Bạn commit mutation hoặc dispatch action bằng string (cart/add).
2. Pinia là nhiều store, bạn compose lúc gọi: useCartStore().add(line). Không có tầng mutation. Action ghi state, hoặc bạn gán thẳng nếu team giữ kỷ luật.
3. TypeScript suy ra this của Pinia và return của setup-store. Module typed của Vuex vật với this và dispatch gõ string. DevTools vẫn chạy; Pinia bỏ yêu cầu mutation sync.
4. Migrate bằng cách cài Pinia cạnh Vuex. Feature mới dùng Pinia store. Tách module nào đã có ranh giới (cart, flags). Bỏ Vuex khi không còn mapState.

// Cùng cart: module Vuex (legacy) vs store Pinia (mặc định Vue 3)
const cartModule = {
  namespaced: true,
  state: () => ({ lines: [] as string[] }),
  mutations: {
    add(state: { lines: string[] }, id: string) {
      state.lines.push(id) // Vuex: chỉ mutation sync
    },
  },
}
export const useCartStore = defineStore('cart', {
  state: () => ({ lines: [] as string[] }),
  actions: {
    add(id: string) {
      this.lines.push(id) // Pinia: action là chỗ ghi
    },
  },
})

Điều gì xảy ra: Cả hai đều giữ lines. Vuex cần module có namespace và một mutation sync. Pinia là một defineStore: TypeScript suy ra this.lines, không có commit. Tách đúng shape này, đừng clone root Vuex.

Lỗi hay gặp

• Triệu chứng: mọi SFC đều re-render. Nguyên nhân: useAppStore với 80 field. Cách xử lý: store có ranh giới và storeToRefs.
• Triệu chứng: cart của user A nằm trong HTML của user B. Nguyên nhân: Pinia hoặc Vuex ở module scope. Cách xử lý: một instance mỗi SSR request.
• Triệu chứng: store treo lúc boot. Nguyên nhân: useX() ở top level của setup. Cách xử lý: gọi useX() trong action.
• Triệu chứng: header nháy logged-out. Nguyên nhân: plugin persist đè payload. Cách xử lý: persist sau khi hydrate, chỉ pref UI.

Tóm tắt: Luồng một chiều nghĩa là view yêu cầu một thay đổi, action ghi state, rồi view re-render từ state đó. Pinia bỏ bước commit thừa của Vuex. Pinia không phải REST cache.

Vì sao quan trọng: Họ cho bạn phác Flux 20 giây, rồi hỏi row product, thanh filter, và toast “đã thêm” nằm ở đâu. Đổ kết quả useFetch vào Pinia để DevTools thấy được là mặc định sai.

1. Cách hoạt động: User click trong component. Component gọi action Pinia (store.add(line)) hoặc Vuex dispatch('cart/add').
2. Action ghi state reactive (Pinia) hoặc commit mutation sync (Vuex). Getter hoặc computed tính ra từ state đó.
3. View re-render. Đó là cả vòng: component → action → state → view. Không có binding store hai chiều.
4. Vòng đời mới là ràng buộc dễ dính. List phía server sẽ stale; draft UI thì không nên stale. Hai bản Product (query và Pinia) sẽ lệch nhau.

export const useCartStore = defineStore('cart', {
  state: () => ({ lines: [] as string[] }),
  actions: {
    add(id: string) {
      this.lines.push(id) // action ghi; view đi theo
    },
  },
})

// Click → action → state → view. Row ở lại trong server cache.
function onAdd(id: string) {
  useCartStore().add(id)
  // filters: route.query. toast: ref local, không phải Pinia
}

Điều gì xảy ra: onAdd là đường ghi duy nhất. Pinia giữ id cart, không phải row product. Filter để trên route.query. Toast là ref local. Sau POST, invalidate cache phía server, đừng coi store.items.push là sự thật.

Lỗi hay gặp

• Triệu chứng: giá cũ sau khi admin sửa. Nguyên nhân: fetchProducts ghi Pinia một lần. Cách xử lý: cache server có key kèm invalidation.
• Triệu chứng: app shell re-render mỗi lần gõ filter. Nguyên nhân: Pinia giữ draft. Cách xử lý: ref local hoặc URL replace đã debounce.
• Triệu chứng: getter gây update thừa. Nguyên nhân: state.list.filter(...) trả array mới mỗi lần đọc. Cách xử lý: cache list suy ra.
• Triệu chứng: persist ghi lúc SSR. Nguyên nhân: $subscribe mọi patch. Cách xử lý: chỉ client và debounce.

Tóm tắt: State global là kiểu session: auth, theme, locale, cart. Draft form để local. Filter cần sống sót sau refresh thì để trên URL. Data server không phải state UI global.

Vì sao quan trọng: “Nhiều component cần thì nhét Pinia” là luật junior. Wizard checkout, filter bảng, toggle theme, và tooltip hover, mỗi cái cần một chỗ riêng. Nếu refresh nên reset thì nó không phải global.

1. Cách hoạt động: Hỏi ba câu. Refresh có giữ không (session)? Link chia sẻ có giữ không (URL)? Chỉ component này cần (ref local)?
2. Global (Pinia hoặc Nuxt useState) cho data kiểu session: identity auth, theme, locale, cart, flag. ref local cho draft, hover, flag tạm.
3. Filter, pagination, tab đang chọn, và sort để trên URL trừ khi bí mật hoặc quá lớn. Auth: Pinia giữ user đã hydrate, không phải access token nếu token có thể để httpOnly.
4. Draft Pinia chỉ dành cho wizard nhiều route, có discard tường minh và tuổi tối đa. Ưu tiên provide/inject hơn một Pinia store nhỏ cho subtree.

const route = useRoute()
const router = useRouter()
const page = computed(() => Number(route.query.page ?? 1))

function setPage(p: number) {
  // replace: click filter không được nhồi history
  router.replace({ query: { ...route.query, page: String(p) } })
}

// draft local, không phải Pinia, không phải URL
const hoverSku = ref<string | null>(null)

Điều gì xảy ra: Pagination nằm trong route.query, nên link và nút back dùng được. replace tránh nhồi history. Hover là ref local vì refresh nên reset. Pinia không nằm trên path này.

Lỗi hay gặp

• Triệu chứng: App.vue re-render mỗi lần gõ. Nguyên nhân: storeToRefs của store quá nặng. Cách xử lý: tách store; subscribe một field.
• Triệu chứng: “link không mở cùng view”. Nguyên nhân: filter nằm trong ref của component. Cách xử lý: đưa vào route.query.
• Triệu chứng: hai tab đè wizard. Nguyên nhân: draft Pinia không có key tab. Cách xử lý: sessionStorage theo tab, hoặc chấp nhận ghi sau cùng.
• Triệu chứng: typeahead nhồi history. Nguyên nhân: router.push mỗi phím. Cách xử lý: debounce replace, hoặc commit lúc submit.

Tóm tắt: Vuex tách commit (mutation sync) khỏi dispatch (action async) để DevTools time-travel được một log thuần. Pinia không tách: action chính là chỗ ghi. Topic này nói về tách đó; 7.5 là ai gọi ai.

Vì sao quan trọng: Có người viết async FETCH trong mutations. Log gãy, race xuất hiện, và câu junior là “vì Vue bảo vậy”. Chốt senior: tách này tồn tại vì DevTools, và Pinia đã bỏ.

1. Cách hoạt động: commit('SET_USER', user) chạy mutation ngay. Mutation phải sync và đủ thuần để replay. Không được await.
2. dispatch('fetchUser', id) chạy action. Action có thể async, gọi API, rồi commit. dispatch trả Promise của action; commit không trả gì hữu ích.
3. Component gần như luôn dispatch. Tách tồn tại để Vuex DevTools ghi một list patch sync. JavaScript chưa bao giờ cần hai loại hàm.
4. Trong Pinia không có commit. Action ghi this.user = …. Team muốn audit log thì bọc phần ghi trong named action kèm plugin. Đừng bịa tầng mutation.

// Vuex: dispatch → action → commit → mutation (sync) → state
const mutations = {
  SET_USER(state: { user: User | null }, user: User) {
    state.user = user // không await: DevTools replay dòng này
  },
}
const actions = {
  async fetchUser({ commit }: { commit: Function }, id: string) {
    commit('SET_USER', await api.getUser(id))
  },
}

// Pinia: action chính là chỗ ghi. Không commit.
export const useUserStore = defineStore('user', {
  state: () => ({ user: null as User | null }),
  actions: {
    async fetchUser(id: string) {
      this.user = await api.getUser(id)
    },
  },
})

Điều gì xảy ra: Vuex cần hai hàm cho một lần ghi. dispatch trả Promise để caller await được. Pinia gộp thành một action. async trong mutation Vuex sẽ gãy log DevTools và race với commit sau.

Lỗi hay gặp

• Triệu chứng: DevTools time-travel lệch. Nguyên nhân: await trong mutation. Cách xử lý: đưa I/O sang action, rồi commit.
• Triệu chứng: caller race sau commit. Nguyên nhân: họ tưởng nhận được Promise. Cách xử lý: dispatch rồi await action.
• Triệu chứng: wrapper “mutations.ts” trong Pinia. Nguyên nhân: port Vuex 1:1. Cách xử lý: để action ghi; chỉ thêm plugin khi cần audit.
• Triệu chứng: $patch phá invariant hai field. Nguyên nhân: component chỉ patch một field. Cách xử lý: named action ghi cả hai.

Tóm tắt: 7.4 đã nói phần cơ bản commit khác dispatch. Topic này là dispatch có namespace, giá trị trả về, và ai gọi ai. dispatch gọi một action; cycle lúc setup mới là bug.

Vì sao quan trọng: Logout phải xóa cart, overlay UI, và session. Người phỏng vấn hỏi ai gọi ai, và chuyện gì xảy ra khi useCartStore và useAuthStore import nhau lúc setup.

1. Cách hoạt động: Vuex dispatch('cart/add') là lời gọi có namespace. dispatch('user/logout', null, { root: true }) gọi sang module khác. Giá trị trả về là Promise của action đó.
2. Pinia không có dispatch kiểu chuỗi. Gọi useOtherStore() trong action, không ở top level lúc setup store. Chốt một hướng gọi: auth được phép reset cart; cart không được hydrate auth.
3. Nếu foo import bar và bar import foo lúc setup, một trong hai là undefined lần gọi đầu. Module Vuex có namespace cũng cycle qua dispatch. Cycle là bug kiến trúc.
4. Với logout, một action owner hoặc resetAll() rõ trong composer thắng một mạng import. $reset() không chạy teardown tùy chỉnh (websockets). Ghép với một action dispose().

export const useAuthStore = defineStore('auth', {
  state: () => ({ user: null as User | null }),
  actions: {
    async logout() {
      await api.logout()
      this.user = null
      // trong action, không ở top level lúc setup
      useCartStore().$reset()
      useUiStore().closeAllOverlays()
    },
  },
})

// Vuex: dispatch('cart/reset', null, { root: true })
// dispatch trả Promise của action để logout await được

Điều gì xảy ra: auth giữ hướng gọi. Cart và UI được reset từ trong logout, lazily, nên không store nào bị import lúc setup. Vuex cũng dispatch một chuỗi có namespace như vậy. Cycle lúc setup sẽ để một store undefined lần gọi đầu.

Lỗi hay gặp

• Triệu chứng: một store undefined lúc boot. Nguyên nhân: hai store import nhau lúc setup. Cách xử lý: gọi useX() trong action.
• Triệu chứng: test logout chỉ pass khi import cart trước. Nguyên nhân: cycle ẩn. Cách xử lý: setActivePinia(createPinia()) rồi assert mọi store theo user đã xóa.
• Triệu chứng: websocket vẫn mở sau $reset(). Nguyên nhân: $reset chỉ reset state. Cách xử lý: action dispose().
• Triệu chứng: hook $onAction lặp. Nguyên nhân: hook dispatch cùng action. Cách xử lý: lọc theo tên hoặc một flag.

Tóm tắt: Hydration SSR của store nghĩa là serialize state Pinia vào payload HTML rồi gắn lên client trước first paint. Cross-request state pollution là store còn sót của User A hiện trong HTML của User B, vì một Pinia bị dùng lại giữa các request.

Vì sao quan trọng: Cart của User A hiện trong HTML của User B. Hoặc header nháy logged-out sau khi SSR render đúng. Họ muốn instance theo request, payload, và thứ bạn không được persist.

1. Cách hoạt động: Tạo một Pinia mỗi SSR request. Thứ gì còn trong store lúc renderToString kết thúc đều có thể lọt vào payload HTML.
2. Trên client, gắn cùng state trước first paint để hydration khớp. @pinia/nuxt lo tạo theo request kèm payload. Tự viết window.__PINIA__ thì dễ sai.
3. Có trong payload: profile public đã dùng trong HTML, flag đã gate SSR, cart ids nếu header render count. Không: refresh token, full ACL matrix, list useAsyncData bị nhân đôi.
4. Nuxt useState là state reactive theo request cho một giá trị. Dùng cho flag SSR nhẹ. Dùng Pinia khi có behavior (action, nhiều field, DevTools).

// ❌ pinia ở module scope: user A rò sang user B (ô nhiễm)
export const pinia = createPinia()

// ✅ một pinia mỗi request; serialize pinia.state.value vào payload
export async function renderOk(cookie: string) {
  const pinia = createPinia()
  const app = createSSRApp(Root)
  app.use(pinia)
  useAuthStore(pinia).hydrateFrom(cookie)
  const html = await renderToString(app)
  return { html, state: pinia.state.value }
}

Điều gì xảy ra: Export sai là singleton của cả process. Hai SSR request chồng nhau sẽ share user. Cách đúng tạo Pinia mới, hydrate từ cookie của request đó, rồi gửi pinia.state.value trong payload. Cài payload đó trước first paint, không phải trong onMounted.

Lỗi hay gặp

• Triệu chứng: cart user A trong HTML user B. Nguyên nhân: Pinia ở module scope. Cách xử lý: createPinia() trong request handler (hoặc @pinia/nuxt).
• Triệu chứng: header nháy logged-out. Nguyên nhân: plugin persist phía client đè payload. Cách xử lý: apply payload trước; persist chỉ pref UI.
• Triệu chứng: lệch hydration ở header. Nguyên nhân: store cài trong onMounted. Cách xử lý: cài trước first paint.
• Triệu chứng: HTML 2 MB. Nguyên nhân: serialize list useAsyncData vào Pinia. Cách xử lý: để payload Nuxt phụ trách các key đó.

Tóm tắt: Server cache (useAsyncData, TanStack Query) phụ trách entity refetch được với key, độ cũ, và invalidation (cố ý làm cache miss). Pinia phụ trách ý nghĩa chỉ-client. Đừng dùng Pinia làm HTTP cache.

Vì sao quan trọng: Admin sửa giá; trang product vẫn hiện giá hôm qua vì fetchProducts ghi Pinia lúc onMounted và không ai gọi refreshNuxtData. Họ muốn tách rõ và câu chuyện mutation, kể cả cart.

1. Cách hoạt động: Hỏi “backend trả cái này được không?” Nếu có, đó là server state: cho nó cache key, TTL (time to live), và đường invalidation.
2. Pinia phụ trách ý nghĩa chỉ-client: UX session, draft, selection chưa vào URL, overlay optimistic. Hai bản Product sẽ lệch.
3. Cart: list id trong Pinia (hoặc cookie) kèm product detail từ server cache. Cart Pinia nhét full product object thì thành máy giá cũ.
4. Sau POST hoặc PATCH, invalidate. Đừng lấy “giữ Pinia sync” làm kiến trúc. Payload SSR đã là server cache; nhét cùng blob vào Pinia nhân đôi memory và chi phí hydration.

async function renameProduct(id: string, name: string) {
  await $fetch(`/api/products/${id}`, {
    method: 'PATCH',
    body: { name },
  })
  // invalidate cache server: đừng store.items.push
  await refreshNuxtData(`product:${id}`)
  await refreshNuxtData('product-list')
  useUiStore().lastSavedAt = Date.now() // overlay chỉ-client
}

Điều gì xảy ra: PATCH tới API. Rồi cả key detail và key list được refresh. Pinia chỉ ghi lastSavedAt: overlay, không phải Product thứ hai. Invalidate một lần, mọi màn hiện tên mới.

Lỗi hay gặp

• Triệu chứng: giá hôm qua sau PATCH của admin. Nguyên nhân: list Pinia đổ một lần trong onMounted. Cách xử lý: useAsyncData có key kèm refreshNuxtData.
• Triệu chứng: cart hiện SKU đã xóa. Nguyên nhân: full product object nằm trong Pinia. Cách xử lý: lưu id; đọc detail từ server cache.
• Triệu chứng: ba array phải sync tay. Nguyên nhân: dual-write Pinia và cache. Cách xử lý: mỗi sự thật một owner; invalidate sau POST.
• Triệu chứng: key useFetch đụng nhau xuyên trang. Nguyên nhân: key generic 'list'. Cách xử lý: nhét route vào key, đừng dump vào Pinia.