Bài này nói về TypeScript mức senior cho phỏng vấn Vue: làm type không cho phép state sai. UserId không truyền vào chỗ cần OrderId được, UI không thể vừa loading vừa error, DTO PATCH không gửi được passwordHash. Dành cho engineer đã compile được, giờ cần một quy tắc team có lý do.

Đọc 2.1 trước (interface vs type, generic, narrowing). Người phỏng vấn hỏi discriminated union và một useFetch không nói dối, nhiều hơn Partial vs Pick. Rồi đọc 2.2 về utility, guard, mapped và conditional type. Ưu tiên Vue 3 script setup; React là bản đối chiếu. Với mỗi topic, nêu rõ type ngăn gì, runtime vẫn cho phép gì, và bạn bắt phần còn lại bằng parser hoặc test thế nào.

Tóm tắt: interface và type đều đặt tên shape object. Dùng type cho union, alias mapped và conditional, và brand. Dùng interface khi cần declaration merging.

Vì sao quan trọng: Một người trong team interface một union các state API “cho consistency”. Người khác từ chối interface vì “type hiện đại hơn”. Người phỏng vấn muốn quy tắc team có lý do, không phải sở thích Twitter. Hai file interface User merge mà không cảnh báo. Đó là cách bạn mất một field đang nhìn trước mặt.

1. Cách hoạt động: Cả hai mô tả shape object. type còn alias được union, intersection, mapped type, hoặc primitive. interface không đặt tên được union.
2. interface declaration merging: hai interface User cùng scope thành một. Đó là mục đích của Window, module augmentation Vue, và Express.
3. extends trên interface thì fail rõ khi xung đột. Intersection A & B có thể kéo field về never thầm hơn.
4. Shape object dùng được cả hai. Theo repo. Style lẫn trong một PR mới là chi phí thật, không phải chuyện chọn keyword “hiện đại”.

type ApiState<T> =
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: Error }

// interface: merge là mục đích, một env.d.ts
declare global {
  interface Window {
    analytics?: { track(event: string): void }
  }
}

interface User { id: string }
interface User { name: string } // merge, có thể giấu field thiếu

Điều gì xảy ra: ApiState là union, nên phải là type. Window.analytics là declaration merging, nên phải là interface. Hai khối interface User thành một type; file thứ ba có thể thêm field bạn không thấy trong PR.

Lỗi hay gặp

• Triệu chứng: union các state API là interface. Nguyên nhân: “luôn dùng interface”. Cách xử lý: type cho union.
• Triệu chứng: một field biến mất lúc review. Nguyên nhân: interface User khác đã merge. Cách xử lý: alias type cho DTO, hoặc một interface mỗi tên.
• Triệu chứng: A & B làm field thành never. Nguyên nhân: intersection không tương thích. Cách xử lý: extends hoặc union.
• Triệu chứng: Vue declare module viết lại thành type. Nguyên nhân: “type thì hiện đại”. Cách xử lý: giữ interface để nó merge.

Tóm tắt: Generic là type parameter: đối số của hàm, nhưng cho type. Dùng khi caller biết type mà bạn không biết. Ràng buộc những gì implementation cần. Đừng generic một type giả ở ranh giới network.

Vì sao quan trọng: Bạn bọc fetch hoặc viết composable kiểu useAsyncData. Candidate mức mid viết function wrap<T>(value: T) rồi dừng. Người phỏng vấn muốn ràng buộc, default, và khi nào không generic. useFetch<T>() không có parser là type bạn truyền vào, không phải type bạn kiếm được.

1. Cách hoạt động: <T> khai báo lúc gọi (hoặc trên type alias). TypeScript suy ra T từ đối số khi được. Nếu mọi caller viết <Foo>, inference đã thất bại.
2. T extends { id: string } ràng buộc những gì thân hàm dùng được. Đừng generic “phòng khi”. Nếu T chỉ xuất hiện một lần như annotation trả về, bạn muốn một type có tên.
3. Mặc định unknown ở ranh giới network để inference không thành {}. Parse (zod) hoặc truyền parse: (data: unknown) => T để T là type kiếm được.
4. Composable Vue: ref<T | null>(null) kèm parser. React useQuery<T> cùng một kiểu nói dối nếu fetcher trả any.

type JsonParser<T> = (data: unknown) => T

export function useApi<T>(url: string, parse: JsonParser<T>) {
  const data = ref<T | null>(null)
  const error = ref<Error | null>(null)
  async function reload(signal?: AbortSignal) {
    const raw: unknown = await api.get(url, { signal })
    data.value = parse(raw) // T kiếm được, không phải assert
  }
  return { data, error, reload }
}

function upsertById<T extends { id: string }>(rows: T[], row: T): T[] {
  return [...rows.filter((r) => r.id !== row.id), row]
}

Điều gì xảy ra: useApi không tin URL. Caller đưa parse, nên T là thứ hàm đó trả về. upsertById ràng buộc id vì thân hàm cần nó. useFetch<User>() với as User bên trong vẫn compile và sai trên trang lỗi HTML 200.

Lỗi hay gặp

• Triệu chứng: useFetch<User>() trả HTML như User. Nguyên nhân: assertion, không parser. Cách xử lý: unknown + parse.
• Triệu chứng: T extends object vẫn không đọc id. Nguyên nhân: ràng buộc yếu. Cách xử lý: T extends { id: string }.
• Triệu chứng: caller luôn viết <Foo>. Nguyên nhân: không đối số nào nhắc T. Cách xử lý: một parse hoặc giá trị mẫu.
• Triệu chứng: function wrap<T>(x: T): T chỉ trả x. Nguyên nhân: generic để khoe. Cách xử lý: xóa <T>.

Tóm tắt: Narrowing là cách TypeScript thu hẹp union sau một check: typeof, in, instanceof, equality, và discriminated union. Model UI async bằng union có tag, để loading và error không thể cùng true.

Vì sao quan trọng: Spinner, form, và banner lỗi có thể hiện cùng lúc vì state là { loading: boolean; data?: T; error?: Error }. Người phỏng vấn muốn discriminated union như một state machine UI, không phải typeof trên string.

1. Cách hoạt động: Sau if (state.status === 'success'), TypeScript chỉ còn giữ variant đó. Tag literal (status) là discriminant.
2. typeof / in / instanceof / equality cũng narrow. instanceof fail khi qua iframe: hãy dùng một kind do bạn định nghĩa cho giá trị đi xuyên realm.
3. Cờ boolean ổn cho nút một dòng, nhưng sai khi có retry hoặc stale-while-revalidate. data stale là variant khác (error + data tùy chọn), không phải data? trên mọi state.
4. Narrowing là lúc compile. JSON vẫn unknown đến khi có parser. Template Vue thường mất narrowing. Hãy derive variant đã gán nhãn trong script.

type AsyncState<T, E = Error> =
  | { status: 'idle' }
  | { status: 'loading'; abort: AbortController }
  | { status: 'success'; data: T }
  | { status: 'error'; error: E; data?: T } // có data = stale

function label(state: AsyncState<User>) {
  if (state.status === 'success') return state.data.name
  if (state.status === 'error') return state.error.message
  return '…'
}

function assertNever(x: never): never {
  throw new Error(String(x))
}

Điều gì xảy ra: Sau check success, data là bắt buộc. loading && error không compile vì hai tag là variant khác nhau. assertNever là switch đủ nhánh cho status: 'refreshing' sau này bạn chưa xử lý. data tùy chọn trên error là stale-while-revalidate, không phải boolean thứ ba.

Lỗi hay gặp

• Triệu chứng: spinner và error cùng lúc. Nguyên nhân: { loading, error, data? }. Cách xử lý: union status.
• Triệu chứng: state.data.name trong template lúc loading. Nguyên nhân: template mất narrowing. Cách xử lý: computed trong script.
• Triệu chứng: instanceof Array false từ iframe. Nguyên nhân: realm. Cách xử lý: Array.isArray / một kind.
• Triệu chứng: status mới vẫn compile mọi chỗ. Nguyên nhân: không check never. Cách xử lý: assertNever trong switch.

Tóm tắt: Utility có sẵn viết lại một type: Partial, Pick, Omit, Record, ReturnType, Awaited, NonNullable. Chúng là structural và nông. Hãy compose một DTO tường minh; đừng ship Partial<User> làm body PATCH.

Vì sao quan trọng: Bạn cần body PATCH cho User. Ai đó viết Partial<User> rồi ship id và passwordHash như field ghi tùy chọn. Người khác dùng Omit<User, 'password'> và nghĩ credentials.password lồng bên trong đã biến mất. Hàm HTTP vẫn nhận nguyên User.

1. Cách hoạt động: Partial<T> biến mọi key thành tùy chọn. Pick<T, K> giữ key. Omit<T, K> là { [P in Exclude<keyof T, K>]: T[P] } và nông: object lồng được copy nguyên.
2. Record<K, V> là index của các key K. Record<string, V> giấu key thiếu. Record<Role, V> với union role mới hữu ích.
3. ReturnType<typeof fn> và Awaited<T> nối các wrapper promise. Type client một lần; đừng tự bóc ba lớp Axios.
4. Readonly<T> là lúc compile. Object.freeze freeze nông lúc runtime. Vue readonly() là proxy. Chúng không thay thế lẫn nhau. NonNullable<T> chỉ bỏ null | undefined ở tầng trên.

type User = {
  id: string
  name: string
  email: string
  role: 'admin' | 'user'
  passwordHash: string
  profile: { bio: string; passwordHint: string }
}

type UserPatch = Partial<Pick<User, 'name' | 'email' | 'role'>>
type UserPublic = Omit<User, 'passwordHash'> // passwordHint lồng vẫn còn

function patchUser(id: string, body: UserPatch) {
  return api.patch('/users/' + id, body)
}

const ok: UserPatch = { name: 'Ada' }
// patchUser(id, fullUser) không compile: DTO đã làm đúng việc

Điều gì xảy ra: UserPatch gửi được name, email, hoặc role, không gì khác. User đầy đủ không assign được, nên passwordHash không lọt ra network. UserPublic vẫn còn profile.passwordHint vì Omit nông: bạn phải tự gỡ object lồng.

Lỗi hay gặp

• Triệu chứng: PATCH làm trống id hoặc gửi passwordHash. Nguyên nhân: Partial<User>. Cách xử lý: Partial<Pick<User, writable keys>>.
• Triệu chứng: passwordHint lồng vẫn còn trên type public. Nguyên nhân: Omit nông. Cách xử lý: gỡ object lồng.
• Triệu chứng: Record<string, Role> nhận mọi key. Nguyên nhân: index signature. Cách xử lý: Record<Role, V> với union.
• Triệu chứng: spread partial vào User vẫn compile. Nguyên nhân: as User. Cách xử lý: DTO là type đối số, không assertion.

Tóm tắt: Predicate (x is T) hoặc assertion (asserts x is T) là contract bạn ký với compiler. Kiểm đủ field hoặc parse. Đừng bao giờ return true as x is T. Ở ranh giới network, type là unknown.

Vì sao quan trọng: Một isUser(x: unknown): x is User trả true nếu 'id' in x thì vẫn compile, và sai. Người phỏng vấn muốn predicate bạn dám ký, và kỷ luật không as User ở ranh giới tin cậy.

1. Cách hoạt động: Sau if (isAbortError(e)), TypeScript giữ DOMException. Thân hàm không bị kiểm theo predicate: bạn có thể nói dối.
2. asserts x is T phải throw khi fail. Dùng lúc startup (assert(env.API_URL)), không dùng trên đường render. Thân hàm chỉ return thì crash chỉ thấy ở production.
3. Ở ranh giới network hoặc storage, parse (zod / Valibot) rồi infer T từ schema. Guard viết tay dành cho union của bạn (isAbortError, isSuccess).
4. instanceof fail khi qua iframe và package bị nhân đôi. Ưu tiên discriminant kind do bạn đặt. Narrow lại trong Vue watch và interceptor axios: chúng mất phần đã narrow.

function isAbortError(e: unknown): e is DOMException {
  return e instanceof DOMException && e.name === 'AbortError'
}

function assertUnreachable(x: never): never {
  throw new Error('unreachable: ' + String(x))
}

function parseUser(data: unknown): User {
  return UserSchema.parse(data) // throw → error state của caller
}

// ❌ nói dối: object chỉ có id thì không phải User
function isUser(x: unknown): x is User {
  return typeof x === 'object' && x !== null && 'id' in x
}

try {
  await reload()
} catch (e: unknown) {
  if (isAbortError(e)) return
  throw e
}

Điều gì xảy ra: isAbortError kiểm name, không chỉ instanceof, nên một DOMException ngẫu nhiên không bị coi là cancel. parseUser throw khi payload sai, nên error state của caller là thật. isUser vẫn compile và để { id: 1 } lọt như User. assertUnreachable là helper never phủ hết nhánh.

Lỗi hay gặp

• Triệu chứng: { id } lọt như User. Nguyên nhân: 'id' in x. Cách xử lý: đủ field, hoặc Zod.
• Triệu chứng: x.name.toUpperCase() crash sau guard. Nguyên nhân: chỉ kiểm typeof === 'object'. Cách xử lý: parse hoặc kiểm name.
• Triệu chứng: x is User[] sau Array.isArray. Nguyên nhân: phần tử chưa type. Cách xử lý: kiểm phần tử hoặc parse.
• Triệu chứng: assert(x) không throw rồi crash sau. Nguyên nhân: thân rỗng. Cách xử lý: throw khi fail.

Tóm tắt: Mapped type là “với mỗi key của T, tạo một property”. Map trên keyof T để form và error map không lệch. Ưu tiên Partial<Record<keyof T, string>> hơn việc viết lại Readonly.

Vì sao quan trọng: Người phỏng vấn không muốn bạn viết lại Readonly. Họ muốn một mapping production: error form gắn theo form, hoặc object “mọi flag đều boolean”, không list key song song có thể lệch.

1. Cách hoạt động: { [K in keyof T]: … } đi qua các key. Mapped type homomorphic giữ readonly và optional đến khi bạn viết lại key theo cách làm chúng bị reset.
2. Modifier: +? / -? và readonly / -readonly. -? bắt buộc mọi key: đó là map “touched” Record<keyof T, boolean>.
3. Key remapping (as) dành cho emit update:${K} và để bỏ key bằng never. Nó thừa nếu chỉ đổi id thành userId một lần.
4. keyof (A | B) là giao của các key, không phải union hai form. Map từng member nếu ý bạn là hai form. Mapped type nông; deep-partial rất dễ sai.

type FormErrors<T> = Partial<Record<keyof T, string>>
type Touched<T> = { [K in keyof T]-?: boolean }

type Profile = { name: string; email: string; age: number }
type ProfileErrors = FormErrors<Profile>
type ProfileTouched = Touched<Profile>

function showErrors(errors: ProfileErrors) {
  if (errors.email) banner(errors.email)
  // thêm phone vào Profile thì chỗ này phải quyết
}

type UpdateEmit<T> = {
  [K in keyof T as `update:${Extract<K, string>}`]: [T[K]]
}

const errors: ProfileErrors = { email: 'required' }
const touched: ProfileTouched = { name: true, email: false, age: false }

Điều gì xảy ra: ProfileErrors có thể có name, email, hoặc age, không key nào khác. Thêm phone vào Profile thì ProfileErrors và Touched buộc UI phải quyết. Touched dùng -? nên mọi key là bắt buộc. UpdateEmit remap mỗi key thành update:${K} cho emit có type.

Lỗi hay gặp

• Triệu chứng: field phone mới không có chỗ error. Nguyên nhân: interface error viết tay. Cách xử lý: map keyof T.
• Triệu chứng: union hai form mất key. Nguyên nhân: keyof (A | B) là giao. Cách xử lý: map từng phần tử.
• Triệu chứng: cờ optional biến mất. Nguyên nhân: viết lại không homomorphic. Cách xử lý: { [K in keyof T]: … } hoặc giữ Partial.
• Triệu chứng: Object.keys(errors) là string[]. Nguyên nhân: TS widening. Cách xử lý: helper có type, không as.

Tóm tắt: T extends U ? X : Y cho library rẽ nhánh một type. Dùng khi một hàm có hai shape trả về thật, hoặc khi bạn infer để bóc. Đừng dùng trên trang Vue: overload hoặc hai hàm suy type tốt hơn.

Vì sao quan trọng: Người phỏng vấn muốn một chỗ rẽ production: hàm trả void hay { data: T } tùy T, hoặc bóc payload emit Vue. Họ không muốn bạn tự viết NonNullable trên bảng, trừ khi đang hỏi infer.

1. Cách hoạt động: T extends U ? X : Y chọn X khi T gán được cho U. infer R đặt tên một mảnh của U để bạn trả về (Awaited, payload của event).
2. T trần phân phối trên union: ToArray<string | number> thành string[] | number[]. Bọc [T] extends [U] khi không được phân phối.
3. never extends mọi thứ. Tuple rỗng có thể biến generic thành never rồi khớp nhánh sai mà không cảnh báo. Default generic là unknown, không phải any, không thì nhánh sai chết.
4. Nếu bạn cần infer hơn một lần trong code app, nhiều khả năng bạn muốn ReturnType, Parameters, hoặc Awaited. Ưu tiên chúng trong Vue SFC.

type ApiOk<T> = T extends void ? { ok: true } : { ok: true; data: T }

type Unwrap<T> = T extends Promise<infer R> ? Unwrap<R> : T

type ToArray<T> = T extends unknown ? T[] : never
type NoDistribute<T> = [T] extends [unknown] ? T[] : never

async function mutate<T>(path: string, body: unknown): Promise<ApiOk<T>> {
  const data = await api.post(path, body)
  // parse ở ranh giới; conditional type là contract của caller
  return (data === undefined ? { ok: true } : { ok: true, data }) as ApiOk<T>
}

type A = ToArray<string | number> // string[] | number[]
type B = NoDistribute<string | number> // (string | number)[]

Điều gì xảy ra: ApiOk<void> là { ok: true }. ApiOk<User> thêm data. ToArray phân phối, nên union thành union các mảng. NoDistribute bọc T trong tuple và trả một mảng của union. Unwrap là infer dùng như Awaited. as ApiOk<T> chỉ đúng nếu parser đã check data.

Lỗi hay gặp

• Triệu chứng: ToArray<A | B> là A[] | B[] khi bạn muốn (A | B)[]. Nguyên nhân: phân phối. Cách xử lý: [T] extends [unknown].
• Triệu chứng: nhánh sai không bao giờ khớp. Nguyên nhân: T = any. Cách xử lý: default unknown.
• Triệu chứng: [] vào nhánh never. Nguyên nhân: never extends mọi thứ. Cách xử lý: ràng buộc hoặc bọc tuple.
• Triệu chứng: suy type Vue SFC chết. Nguyên nhân: return conditional trong composable. Cách xử lý: hai hàm hoặc overload.

Tóm tắt: Template literal type nối các string literal để emit('update:modelValue') không emit được field ngoài prop. Một ví dụ production là đủ: update:${keyof props} hoặc on${Capitalize<K>}.

Vì sao quan trọng: Tên event, key i18n, hoặc CSS var phải khớp một nguồn sự thật. event: string trên bus vẫn compile user:created khác userCreated. Chúng nổ tổ hợp nếu bạn interpolate string. Đổi tên prop rồi nhìn emit fail trong tsc.

1. Cách hoạt động: `${K}` nối literal. Phải có as const trên object nguồn, không thì bạn interpolate string. keyof T & string bỏ number | symbol.
2. Uppercase / Capitalize dành cho tên kiểu protocol (onChange), không phải chữ hiển thị. Chuỗi UI thuộc i18n.
3. Path `/users/${string}` không validate một id. Param branded vẫn phải nằm ở đối số của hàm.
4. Union template khổng lồ làm chậm tsc. Tách theo feature. Đừng type cả router bằng template khi Vue Router 4 RouteMap hoặc Nuxt typedPages đã có.

type UpdateEmits<T> = {
  [K in keyof T & string as `update:${K}`]: [value: T[K]]
}

type UserForm = { name: string; email: string }
type UserFormEmits = UpdateEmits<UserForm>
// các key: 'update:name' | 'update:email'

const ROUTES = {
  home: '/',
  user: '/users/:id',
} as const

type RouteName = keyof typeof ROUTES
function go(name: RouteName) {
  return ROUTES[name]
}
// go('Home') là lỗi type: không phải 'update:Name', không phải 'change:name'

Điều gì xảy ra: UpdateEmits remap mỗi key form thành update:${K} với payload khớp. Đổi email thành mail thì listener vỡ trong tsc. ROUTES cần as const, không thì go nhận string. Template path không phải chỗ kiểm id.

Lỗi hay gặp

• Triệu chứng: emit('update:modelvalue') vẫn compile. Nguyên nhân: event: string. Cách xử lý: mapped update:${K}.
• Triệu chứng: key interpolate thành string. Nguyên nhân: thiếu as const hoặc T & string. Cách xử lý: cả hai.
• Triệu chứng: tsc chậm sau union path. Nguyên nhân: template tổ hợp. Cách xử lý: tách theo feature; tin router.
• Triệu chứng: `/users/${string}` nhận number. Nguyên nhân: đó không phải check id. Cách xử lý: param branded.

Tóm tắt: Brand ID hay bị trộn để getUser(orderId) thành lỗi type. Ra ngoài vẫn là string. Parse ở biên; as UserId chỉ sống trong parser đó.

Vì sao quan trọng: getUser(orderId) compile vì cả hai đều là string. Đó là sự cố production. Người phỏng vấn muốn lỗi type mà không cần object wrapper lúc runtime.

1. Cách hoạt động: type UserId = string & { readonly __brand: 'UserId' }. Brand bị xóa lúc runtime. Hai brand dùng chung __brand: string có thể gán nhầm cho nhau: dùng literal độc nhất.
2. Ở biên (route param, JSON), parseUserId trả UserId. Trong app, getUser chỉ nhận UserId. Zod .brand<'UserId'>() là bản mình ship.
3. Đừng brand mọi string ngay từ đầu (Email, Url). Brand ID hay bị trộn: UserId, OrgId, OrderId.
4. Vue route param vẫn string đến khi parent route parse một lần. Đừng as xuyên cây component. Giữ collection generic (Set<UserId>).

type UserId = string & { readonly __brand: 'UserId' }
type OrderId = string & { readonly __brand: 'OrderId' }

function parseUserId(raw: string): UserId {
  if (!raw.startsWith('usr_')) throw new Error('bad user id')
  return raw as UserId // chỉ trong parser
}

function getUser(id: UserId) {
  return api.get('/users/' + id)
}

declare const orderId: OrderId
// getUser(orderId) // lỗi: đúng là cả tính năng

const fromRoute = parseUserId(route.params.id as string)
getUser(fromRoute)

Điều gì xảy ra: UserId và OrderId đều là string lúc runtime, nên JSON và URL vẫn là string. getUser(orderId) là lỗi type. as UserId chỉ được phép trong parseUserId. Parent route parse một lần; child nhận UserId.

Lỗi hay gặp

• Triệu chứng: getUser(orderId) compile. Nguyên nhân: cả hai là string. Cách xử lý: brand với literal độc nhất.
• Triệu chứng: as UserId cạnh JSON.parse. Nguyên nhân: bỏ parser. Cách xử lý: chỉ parseUserId.
• Triệu chứng: hai brand gán được cho nhau. Nguyên nhân: __brand: string. Cách xử lý: literal độc nhất 'UserId' khác 'OrderId'.
• Triệu chứng: mọi child đều as route param. Nguyên nhân: không parse ở parent. Cách xử lý: parse một lần.

Tóm tắt: satisfies kiểm value với một type mà không nới inferred type của value. Ghép as const satisfies T ở biên config và catalog để typeof routes.home vẫn '/'.

Vì sao quan trọng: as const làm object routes hẹp quá, không gán được chỗ cần Record<string, string>, hoặc as Record<…> nới value và mất key literal. Người phỏng vấn muốn biết satisfies đổi gì.

1. Cách hoạt động: Value được kiểm với T và giữ inferred type của chính nó. as const satisfies T cho cả literal lẫn phép kiểm đủ. TS 4.9+: nâng version, đừng polyfill bằng double assertion.
2. as const một mình không chứng minh mọi key đều có. as Record<…> nới literal. Key thừa vẫn được phép trừ khi type cấm.
3. satisfies Record<string, boolean> không bắt tên flag gõ sai. satisfies Record<KnownFlag, boolean> thì có. Hoặc đảo: as const satisfies rồi suy KnownFlag từ object.
4. Chỉ kiểm lúc compile. JSON remote vẫn unknown. Đừng satisfies kết quả JSON.parse. Đừng dùng trên defineProps.

const flags = {
  newCheckout: false,
  betaNav: true,
} as const satisfies Record<string, boolean>

type Flag = keyof typeof flags // 'newCheckout' | 'betaNav'

const routes = {
  home: '/',
  users: '/users',
} as const satisfies Record<string, `/${string}`>

function go(name: keyof typeof routes) {
  return routes[name] // typeof routes.home là '/'
}

// flags.typo = true // lỗi: 'typo' không phải Flag

Điều gì xảy ra: flags phải là object các boolean, nhưng Flag vẫn là union key literal. routes.home vẫn '/', không phải string. Key gõ sai là lỗi type. Thêm key bắt buộc vào contract thì satisfies fail ngay tại object.

Lỗi hay gặp

• Triệu chứng: typeof routes.home là string. Nguyên nhân: as Record<string, string>. Cách xử lý: as const satisfies.
• Triệu chứng: flag gõ sai vẫn compile. Nguyên nhân: Record<string, boolean>. Cách xử lý: suy key từ object.
• Triệu chứng: satisfies trên JSON.parse. Nguyên nhân: tưởng nó parse. Cách xử lý: unknown kèm schema.
• Triệu chứng: dùng trên defineProps. Nguyên nhân: sai tool. Cách xử lý: defineProps<T>().

Tóm tắt: unknown nghĩa là bạn phải narrow. any lây mọi expression nó đụng. JSON, catch, postMessage, và localStorage bắt đầu là unknown, rồi mới parse.

Vì sao quan trọng: data: any từ JSON.parse, axios, event.data, IndexedDB, postMessage. Người phỏng vấn muốn vì sao unknown là mặc định senior, và khi nào any là ngoại lệ có cân nhắc.

1. Cách hoạt động: unknown gần như không gán được cho gì đến khi bạn narrow. any gán được mọi chỗ và đầu độc bốn mươi dòng sau. never là “chuyện này không xảy ra”.
2. JSON.parse trả any trong lib.dom: bọc lại để trả unknown. Generic default <T = any> phá inference; default là unknown. any[] đi qua map vẫn là any.
3. Chỉ cho any ở lối thoát đã ghi chú: .d.ts hỏng bạn sẽ xóa, hoặc eslint-disable kèm ticket. Sau parse, Vue ref là User, không phải unknown.
4. object gần như không phải thứ bạn muốn (typeof null === 'object'). Ưu tiên unknown rồi narrow. Viết ref<User | null>(null) để Vue không suy ra any.

function parseJson(raw: string): unknown {
  return JSON.parse(raw) // lib.dom trả any: hãy bọc
}

window.onmessage = (event: MessageEvent<unknown>) => {
  const user = UserSchema.parse(event.data)
  inbox.value = user
}

try {
  await reload()
} catch (e: unknown) {
  if (e instanceof Error) toast(e.message)
}

const selected = ref<User | null>(null) // không phải ref() + null → any

Điều gì xảy ra: parseJson chặn JSON.parse rò any. MessageEvent<unknown> buộc parse trước khi inbox nhận User. catch (e: unknown) khớp useUnknownInCatchVariables. ref<User | null>(null) để Vue không suy ra any.

Lỗi hay gặp

• Triệu chứng: bốn mươi dòng không type sau fetch. Nguyên nhân: response.data: any. Cách xử lý: bọc unknown rồi parse.
• Triệu chứng: ref() của null là any. Nguyên nhân: Vue inference. Cách xử lý: ref<User | null>(null).
• Triệu chứng: catch (e) là any. Nguyên nhân: tắt flag. Cách xử lý: useUnknownInCatchVariables.
• Triệu chứng: as User trên JSON.parse. Nguyên nhân: bỏ parser. Cách xử lý: schema.

Tóm tắt: strict: true và isolatedModules: true là sàn cho app Vue 3 + Vite. Đo bằng vue-tsc --noEmit và strictTemplates, không chỉ tsc.

Vì sao quan trọng: Người phỏng vấn hỏi tsconfig của bạn cho app Vue 3 + Vite có gì, và flag nào không thương lượng năm 2026. Họ muốn biết bạn đã ship strict hay mới chỉ nói miệng.

1. Cách hoạt động: strict bật strictNullChecks, noImplicitAny, và strictFunctionTypes. Vite transpile từng file một, nên cần isolatedModules.
2. const enum thành undefined lúc runtime với Vite: hãy dùng union. Cũng nên có noUncheckedIndexedAccess, useUnknownInCatchVariables, verbatimModuleSyntax. skipLibCheck là yes thực dụng cho repo app.
3. vue-tsc --noEmit type-check .vue. tsc thì không. strictTemplates mới bắt props Vue sai. Nhiều team không bao giờ bật.
4. Path alias (@/) phải khớp Vite và tsconfig. Hai nguồn sự thật là “IDE chạy được, build thì fail”. Đừng đánh nhau với tsconfig Nuxt generate; hãy extend.

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "useUnknownInCatchVariables": true,
    "noImplicitOverride": true,
    "verbatimModuleSyntax": true,
    "isolatedModules": true,
    "skipLibCheck": true
  },
  "vueCompilerOptions": {
    "strictTemplates": true
  }
}

Điều gì xảy ra: Mọi flag trong snippet này đều là thứ mình sẽ ship. isolatedModules là lý do cấm const enum. strictTemplates là lý do prop sai trên child fail CI. CI chạy vue-tsc --noEmit, không chỉ tsc, nên SFC cũng được check.

Lỗi hay gặp

• Triệu chứng: const enum là undefined trên trình duyệt. Nguyên nhân: Vite + transpile từng file. Cách xử lý: union.
• Triệu chứng: CI xanh, props Vue sai. Nguyên nhân: chỉ tsc. Cách xử lý: vue-tsc + strictTemplates.
• Triệu chứng: @/ IDE chạy được, build fail. Nguyên nhân: alias lệch. Cách xử lý: một nguồn duy nhất.
• Triệu chứng: strict bật, any khắp nơi. Nguyên nhân: diễn. Cách xử lý: lint ban + bọc client.

Tóm tắt: Type compiler macro Vue 3.3+: defineProps<T>() và defineEmits<{ select: [id: UserId] }>(), rồi để vue-tsc fail parent khi userId sai hoặc thiếu listener.

Vì sao quan trọng: Type component này: v-model, userId branded, variant discriminated, và emit mà parent phải xử lý. So nhanh với React props. Không dùng object defineProps runtime chưa type.

1. Cách hoạt động: defineProps<T>() và defineEmits<{ change: [id: UserId] }>(). v-model là modelValue kèm 'update:modelValue'. Default để trong withDefaults.
2. defineModel<UserId>() là lối tắt 3.4+; khi truyền đi vẫn là modelValue. Props một chiều; mutate một field của prop vẫn type-check được, nhưng vẫn là bug Vue.
3. emits chưa khai báo đi tiếp như event native / vnode attrs, và listener phía parent không có type. Đừng type emit kiểu (e: string, ...args: any[]).
4. React gộp emit vào callback onChange. Vue tách props và emit, nên type của v-model là chuyện riêng. Parse UserId branded ở route phía parent, không as trong con.

const props = withDefaults(
  defineProps<{
    userId: UserId
    variant: 'idle' | 'loading' | 'success' | 'error'
    modelValue: string
    disabled?: boolean
  }>(),
  { disabled: false },
)

const emit = defineEmits<{
  'update:modelValue': [value: string]
  select: [id: UserId]
}>()

function onSelect() {
  emit('select', props.userId)
}
// emit('select', 'raw-string') // lỗi nếu UserId là branded

Điều gì xảy ra: Parent phải truyền userId branded và tag variant. v-model là modelValue kèm emit update. select cần payload UserId, nên chuỗi thô sẽ fail. Default nằm trong withDefaults, không phải object props runtime.

Lỗi hay gặp

• Triệu chứng: emit('update:modelValue') không có payload. Nguyên nhân: emits chưa khai báo. Cách xử lý: defineEmits có type.
• Triệu chứng: mọi parent đều as userId. Nguyên nhân: prop type string. Cách xử lý: UserId branded, parse ở route.
• Triệu chứng: mutate props.user.role “chạy được”. Nguyên nhân: object prop là reference. Cách xử lý: primitive hoặc emit.
• Triệu chứng: runtime defineProps({ userId: String }) trong app TS. Nguyên nhân: thói quen cũ. Cách xử lý: defineProps<T>().