Bài này là cầu nối Vue → React cho phỏng vấn, trên React 19: re-render khác fine-grained reactivity, khi nào effect là bug, khi nào memo chỉ để cho có, và data nên load ở đâu. Dành cho engineer đã ship Vue, giờ cần quyết được chuyện identity, Fiber, và hydration.

Đọc 20.1 trước (reconciliation, JSX, props khác state, effects, refs, fetch). Người phỏng vấn hỏi xoáy vì sao parent re-render kéo cả cây chạy, vì sao useEffect không phải onMounted, và document nên load ở đâu, chứ không phải trivia Hook. Rồi 20.2 cho Context, Suspense, Error Boundaries, và update concurrent. Bản Vue nằm ở tài liệu Vue 3 và State Management. 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: Mô hình React là UI = f(state). Khi state đổi, hàm chạy lại, React diff cây element mới với cây trước đó (reconciliation), rồi commit mutation DOM. Fiber là linked-list các work unit, nhờ đó pha render tạm dừng được.

Vì sao quan trọng: Dashboard Vue 3 mutate một ref thì chỉ widget đó chạy lại. Cùng màn bên React, parent và mọi child re-render khi count đổi. Họ muốn nghe vì sao, bạn còn bọc hết memo không nếu React Compiler đang bật, và key làm gì khi list đổi thứ tự.

1. Cách hoạt động: State, props, hoặc context đổi. React chạy lại hàm component (render phase). Pha đó là pure, và với Fiber thì ngắt được.
2. Reconciliation khớp element type + position, list thì theo key. Cùng type và cùng key thì update tại chỗ (giữ state). Khác type hoặc khác key thì unmount rồi remount (reset state).
3. commit phase áp dụng mutation DOM đồng bộ. Child re-render vì parent đã chạy, trừ khi nó bail out (memo, useMemo identity, hoặc Compiler).
4. Tương đương Vue: Vue 3 patch đồ thị reactivity, nên một ref không kéo cả cây chạy lại. React chạy lại hàm, rồi diff.

// Cùng type + cùng key → update tại chỗ. Type mới hoặc key mới → remount.
{user ? <Editor key={user.id} /> : <Guest />}

// memo so sánh props. Object/hàm mới mỗi render → không bailout
const Child = memo(Expensive)
function Parent() {
  const [n, setN] = useState(0)
  return (
    <Child style={{ margin: 0 }} onClick={() => save(n)} />
  )
}

Điều gì xảy ra: Đổi Editor sang Guest là đổi type, nên state local mất. Child đã được memo, nhưng style={{}} và onClick={() => …} là identity mới mỗi lần Parent render, nên memo không bao giờ bail out. Key trên Editor giữ draft khi user.id ổn định.

Lỗi hay gặp

• Triệu chứng: sửa một ô mà mọi row re-render. Nguyên nhân: parent giữ list và child không bail out. Cách xử lý: key ổn định, rồi Profiler, rồi memo hoặc Compiler, đừng đoán mò.
• Triệu chứng: memo không bao giờ skip. Nguyên nhân: style={{}} hoặc onClick inline. Cách xử lý: identity ổn định, hoặc thôi bọc.
• Triệu chứng: wizard mất draft khi object user bị thay. Nguyên nhân: key={user} dùng identity của object. Cách xử lý: key={user.id}.
• Triệu chứng: đổi type từ Foo sang Bar mà input cũ vẫn còn. Phải remount. Nguyên nhân: tái dùng cùng key trên type khác, cùng vị trí.

Tóm tắt: React mới là function component và Hooks. State của Hook nằm thành một list trên fiber, ghép theo thứ tự gọi. Error Boundaries trong core React 19 vẫn là class (componentDidCatch).

Vì sao quan trọng: Đồng đội viết if (enabled) useEffect(...), hỏi class đã chết chưa trừ Error Boundaries, và muốn map 1:1 từ mixin Options API sang Hooks. Lời gọi Hook sai luật mới là bug thật.

1. Cách hoạt động: Mỗi render, React đi lần lượt các lời gọi Hook theo thứ tự và gắn slot useState / useEffect lên fiber. Thứ tự gọi phải giống nhau mọi render. Đó là lý do có eslint-plugin-react-hooks.
2. if (enabled) useEffect(...) nghĩa là sau khi enabled đảo, mọi Hook phía sau thành slot khác. State gắn nhầm lời gọi. Thân effect có thể có điều kiện; lời gọi Hook thì không.
3. Class vẫn dùng cho cây legacy và Error Boundaries. Core React vẫn cần componentDidCatch / getDerivedStateFromError. Tách class đó ra (hoặc react-error-boundary) và giữ phần còn lại là function.
4. Tương đương Vue: <script setup> giống function component. Mixin Options API là bẫy class/mixin mà Hooks ra đời để thoát.

// Sai luật: sau khi enabled đảo, mọi Hook phía sau thành slot khác
if (enabled) useEffect(() => subscribe(), [])
const [q, setQ] = useState('')

// Hợp lệ: Hook luôn chạy; thân effect mới có điều kiện
useEffect(() => {
  if (!enabled) return
  return subscribe()
}, [enabled])

Điều gì xảy ra: Render đầu với enabled === true, useEffect là slot 0 và useState là slot 1. Sau khi enabled thành false, slot 0 giờ là useState: React đọc string chỗ nó đã lưu effect. Bản hợp lệ luôn gọi cả hai Hook.

Lỗi hay gặp

• Triệu chứng: state lấy nhầm field sau toggle. Nguyên nhân: Hook nằm sau if. Cách xử lý: luôn gọi Hook; để điều kiện ở thân.
• Triệu chứng: “Hooks can only be called inside a function component”. Nguyên nhân: use* trong helper thuần hoặc class. Cách xử lý: đổi tên thành useOnlineStatus và gọi từ component.
• Triệu chứng: cả cây là class “vì lỗi”. Nguyên nhân: trộn UI với componentDidCatch. Cách xử lý: một wrapper Error Boundary.
• Triệu chứng: tắt exhaustive-deps để capture props trong closure. Nguyên nhân: effect nên dùng useEffectEvent hoặc thêm dep.

Tóm tắt: JSX biên dịch thành lời gọi hàm (jsx() / React.createElement). Re-render nghĩa là gọi lại hàm component và trả về mô tả UI mới, không mutate DOM tại chỗ như update fine-grained của Vue.

Vì sao quan trọng: Badge phải ẩn khi bằng 0, nhưng UI lại in ra 0. Ngay cạnh đó, hai sibling trong map bị remount hoặc warn, và trang Next hydrate sai vì <p><div>. Họ muốn phân biệt null với false với 0, và <> có nhận key không.

1. Cách hoạt động: JSX là mô tả UI. {false}, {null}, và {undefined} không render gì. {0}, {NaN}, và {""} render thành text. Boolean bị bỏ qua; số thì không. {count && <Badge />} khi count === 0 sẽ vẽ 0.
2. Bạn trả null khi kiểm soát API và muốn nói “không gì”. Fragment nhóm mà không tạo node DOM. Chỉ <Fragment key> mới nhận key; cú pháp ngắn <> thì không.
3. Lồng HTML không hợp lệ (<p><div>) lúc local vẫn pass được, rồi gãy hydration trên server, vì browser sửa cây trước khi React hydrate.
4. Tương đương Vue: Template Vue biên dịch thành render function kèm patch flag. JSX trong React là lời gọi hàm chưa tối ưu, trừ khi Compiler chạy. v-if không vẽ 0.

{count && <Badge />}            // bẫy: count=0 render "0"
{count > 0 ? <Badge /> : null}  // tường minh, nên dùng
{count ? <Badge /> : null}

// Chỉ Fragment nhận key; <> ngắn thì không
{items.map((item) => (
  <Fragment key={item.id}>
    <dt>{item.term}</dt>
    <dd>{item.def}</dd>
  </Fragment>
))}

Điều gì xảy ra: 0 && <Badge /> ra số 0, React render thành text node. Ternary trả null nên không vẽ gì. Hai sibling trong list cần Fragment có key, không thì remount / warn. <> ngắn không mang được identity đó.

Lỗi hay gặp

• Triệu chứng: hiện 0 chỗ badge phải ẩn. Nguyên nhân: {count && <Badge />}. Cách xử lý: {count > 0 ? <Badge /> : null}.
• Triệu chứng: warn list hoặc remount <dt>/<dd>. Nguyên nhân: <> ngắn trong map. Cách xử lý: <Fragment key={id}>.
• Triệu chứng: lệch hydration Next trên một paragraph. Nguyên nhân: <p><div>. Cách xử lý: lồng HTML hợp lệ; coi warning là fail.
• Triệu chứng: khoảng trống trong flex/grid. Nguyên nhân: div bọc chỗ lẽ ra phải là Fragment.

Tóm tắt: Props là contract chỉ-đọc từ parent chảy xuống. State do component này chịu trách nhiệm (hoặc store, URL, hoặc cache server). Update của React thay identity; Proxy của Vue thấy mutation tại chỗ.

Vì sao quan trọng: Child làm items.push(row) như một bạn Vue mutate list reactive. Parent vẫn cũ, setUser(user) sau user.name = 'x' không có tác dụng, và đưa draft lên root của trang thì dashboard re-render mỗi lần gõ phím.

1. Cách hoạt động: Props đến từ parent. Child không được mutate chúng. Muốn đổi thì gọi onChange (hoặc store). Đó là ownership: ai được phép ghi.
2. setState bail out nếu Object.is thấy cùng reference. user.name = 'x'; setUser(user) không làm gì. Copy: setUser({ ...user, name: 'x' }) hoặc reducer / Immer.
3. Copy props vào state rồi sync bằng effect thường là anti-pattern derived-state. Derive lúc render, hoặc đưa chỗ ghi lên owner.
4. Tương đương Vue: Props Vue vẫn một chiều. Proxy reactive thấy items.push; React thì không. Pinia ghi thì thay field, giống reducer.

// Không làm gì: cùng identity, Object.is bailout
user.name = 'x'
setUser(user)

// Thay: React thấy reference mới
setUser({ ...user, name: 'x' })
setList((list) => [...list, row])

// Child không chịu trách nhiệm props: nó gọi lên
function Row({ item, onRename }: { item: Item; onRename: (name: string) => void }) {
  return <input value={item.name} onChange={(e) => onRename(e.target.value)} />
}

Điều gì xảy ra: Mutate user tại chỗ thì vẫn cùng reference, nên React bỏ qua update. Spread tạo object mới nên input mới đổi được. Row không ghi item; nó hỏi owner qua onRename. Đó là lifting state.

Lỗi hay gặp

• Triệu chứng: UI đứng sau user.name = 'x'. Nguyên nhân: cùng reference. Cách xử lý: copy, hoặc Immer.
• Triệu chứng: child push vào array prop; parent không bao giờ update. Nguyên nhân: mutate props. Cách xử lý: onChange với array mới.
• Triệu chứng: props copy vào state bị cũ. Nguyên nhân: derived-state + effect sync. Cách xử lý: derive lúc render.
• Triệu chứng: dashboard giật vì một input. Nguyên nhân: state lift quá cao. Cách xử lý: đưa draft xuống, hoặc selector của store.

Tóm tắt: Input controlled nghĩa là state React là nguồn sự thật (value + onChange). Uncontrolled nghĩa là DOM mới là nguồn (defaultValue + ref / FormData). Input file uncontrolled vì platform, không phải vì bạn thích.

Vì sao quan trọng: Form 80 field giật mỗi lần gõ, input file “cannot be controlled”, và value={maybeUndefined} sau thành string thì warn uncontrolled→controlled. Họ muốn lúc nào React chịu trách nhiệm value, lúc nào là DOM, và bạn có kéo React Hook Form ra không.

1. Cách hoạt động: Controlled: mỗi lần gõ gọi setState, React re-render, và value={name} là thứ DOM hiện. Thiếu onChange thì field đứng im. Uncontrolled: defaultValue gán sẵn lên DOM; lúc submit bạn đọc qua ref hoặc FormData.
2. Bạn không được flip field từ uncontrolled sang controlled (hoặc ngược lại) giữa các lần render. value={undefined} rồi thành string là warning kinh điển. Input file: đọc e.target.files, đừng bao giờ value={file}.
3. Tương đương Vue: v-model là đường tắt prop + emit. React không có đường tắt: value kèm onChange, hoặc để DOM lo. defineModel vẫn là cặp đó.

// Đứng im: value mà không có onChange
<input value={name} />

// Warning flip nếu name bắt đầu undefined, rồi thành string
<input value={name} onChange={(e) => setName(e.target.value)} />

// File: platform-uncontrolled, đọc FileList
<input type="file" onChange={(e) => setFiles(e.target.files)} />

// Map controlled tương đương v-model="name"
<input value={name} onChange={(e) => setName(e.target.value)} />

Điều gì xảy ra: Input đầu không nhúc nhích vì React chịu trách nhiệm value mà không ai ghi. name bắt đầu là undefined thì field uncontrolled, rồi thành string thì thành controlled. React sẽ warn. Input file chỉ có onChange. Dòng cuối là cặp v-model.

Lỗi hay gặp

• Triệu chứng: field đứng im. Nguyên nhân: value mà không có onChange. Cách xử lý: thêm onChange, hoặc chuyển sang defaultValue.
• Triệu chứng: warning uncontrolled→controlled. Nguyên nhân: value={undefined} rồi thành string. Cách xử lý: value={name ?? ''} từ render đầu tiên.
• Triệu chứng: form giật 60 phím/s. Nguyên nhân: 40 useState ở root của trang. Cách xử lý: RHF, hoặc tách field ra.
• Triệu chứng: input file “cannot be controlled”. Nguyên nhân: value={file}. Cách xử lý: đọc FileList; reset bằng inputRef.current.value = ''.

Tóm tắt: key là identity xuyên các lần render, cùng contract với :key của Vue. Key theo index tái sử dụng nhầm state local khi list đổi thứ tự. Đó là bug input nhảy sang row khác.

Vì sao quan trọng: List todo reorder được dùng key={index}. Sau sort, input uncontrolled hiện text của row sai. map trả <>…</> thì warn, rồi có người “sửa” state cũ bằng key={Math.random()}.

1. Cách hoạt động: Ưu tiên id nghiệp vụ ổn định. Key theo index chỉ chấp nhận cho list tĩnh, không insert, xóa, filter, hay reorder. Key nằm trên element trong array, không phải prop thường mà child đọc.
2. Thiếu key → React fallback sang index bên trong rồi warn. Hai child trong map cần <Fragment key={id}> (<> ngắn không nhận key). Reorder với key index: input uncontrolled dính theo vị trí DOM.
3. key={user.id} trên wizard cố ý remount và xóa state local: đó là API reset hợp lệ. key={Math.random()} remount mỗi lần render và là bug.
4. Tương đương Vue: :key là cùng contract identity. Vue cũng tái sử dụng nhầm instance component khi bạn gắn key v-for theo index rồi sort.

// Key index + reorder → state input đi theo index của row
{todos.map((t, i) => (
  <li key={i}>
    <input defaultValue={t.title} />
  </li>
))}

// Id ổn định. Hai sibling cần Fragment key; <> ngắn thì không
{items.map((item) => (
  <Fragment key={item.id}>
    <dt>{item.term}</dt>
    <dd>{item.def}</dd>
  </Fragment>
))}

Điều gì xảy ra: Sau sort, React tái sử dụng fiber <li key={0}> ở vị trí 0. Value DOM của input uncontrolled giữ nguyên; text title xung quanh đổi. Thành ra sai row. Bản Fragment giữ cặp <dt>/<dd> theo item.id.

Lỗi hay gặp

• Triệu chứng: input hiện sai row sau sort. Nguyên nhân: key={index} + state local/uncontrolled. Cách xử lý: key={todo.id}.
• Triệu chứng: warn list về key. Nguyên nhân: thiếu key, hoặc <> ngắn trong map. Cách xử lý: <Fragment key>.
• Triệu chứng: form reset mỗi lần gõ. Nguyên nhân: key={Math.random()} hoặc key là object mới. Cách xử lý: id ổn định.
• Triệu chứng: wizard không reset. Nguyên nhân: vẫn cùng key={user.id} trong khi field phải xóa. Cách xử lý: đổi key có chủ đích, và nói rõ.

Tóm tắt: useEffect đồng bộ React với hệ thống bên ngoài sau paint: subscription, DOM API, widget third-party. Nó không phải onMounted, không phải computed, cũng không phải API fetch mặc định. Strict Mode gọi setup+cleanup hai lần lúc dev.

Vì sao quan trọng: Đồng đội quen Vue map onMounted + watch(id, fetch) sang useEffect. Strict Mode chạy hai lần, fetch cũ thắng race, rồi useEffect(() => setX(transform(y)), [y]) vẽ một frame UI sai. Khi nào cần effect, và data nên load ở đâu?

1. Cách hoạt động: Effect chạy sau paint. Mảng dependency quyết định lúc nào setup chạy lại. [] là “sau mount”, kèm remount Strict Mode lúc dev, không phải “một lần trong đời tab”. Cleanup phải hoàn tác setup (idempotent).
2. Không thế giới ngoài → không effect. Giá trị suy ra thuộc lúc render. Logic sự kiện user thuộc handler. Load data thuộc TanStack Query, loader của framework, hoặc fetch RSC, xem 20.1.12.
3. Bạn có thể không cần effect: useEffect(() => setX(transform(y)), [y]) là derived state. Tính transform(y) lúc render.
4. Tương đương Vue: watch / onMounted không phải useEffect. watch Vue có thể flush trước paint; effect luôn chạy sau. watchEffect tự track; dep của useEffect liệt kê bằng tay.

// Đồng bộ hệ thống ngoài. Cleanup bắt buộc: Strict Mode remount.
useEffect(() => {
  const el = ref.current
  if (!el) return
  const ro = new ResizeObserver(onSize)
  ro.observe(el)
  return () => ro.disconnect() // phải hoàn tác setup
}, [])

// Có thể không cần effect: suy ra lúc render
// useEffect(() => setTotal(items.reduce(...)), [items])
const total = items.reduce((s, it) => s + it.price, 0)

Điều gì xảy ra: Observer gắn sau paint và gỡ lúc unmount. Strict Mode lúc dev chạy cặp đó hai lần: thiếu cleanup thì leak. total suy ra lúc render, nên paint đầu đã đúng. Fetch trong effect này sẽ race nếu không có AbortController.

Lỗi hay gặp

• Triệu chứng: một frame UI sai, rồi nhảy. Nguyên nhân: useEffect(() => setX(f(y)), [y]). Cách xử lý: suy ra f(y) lúc render.
• Triệu chứng: fetch hai lần lúc dev. Nguyên nhân: remount Strict Mode + fetch trong useEffect. Cách xử lý: Query, hoặc chấp nhận lúc dev và cleanup.
• Triệu chứng: response cũ đè response mới. Nguyên nhân: không abort. Cách xử lý: AbortController hoặc cancel của Query.
• Triệu chứng: websocket leak. Nguyên nhân: thiếu cleanup. Cách xử lý: return unsubscribe; Strict Mode sẽ chứng minh.

Tóm tắt: Suy ra lúc render trước (const total = items.reduce(...)). useMemo là cache opt-in, dep bạn tự liệt kê, không phải computed của Vue. React Compiler, khi bật trong app React 19, đã memo nhiều chỗ như vậy.

Vì sao quan trọng: Đồng đội bọc mọi hằng trong useMemo “như computed”, child memo vẫn re-render vì dep là [] mới mỗi lần, và team vừa bật React Compiler. Có nên useMemo cái này, nó có phải computed, và Compiler đổi gì?

1. Cách hoạt động: Suy ra lúc render trước. Thêm useMemo cho (1) việc đã chứng minh là đắt hoặc (2) ổn định tham chiếu của object/array truyền vào child memo hoặc liệt kê trong dep effect.
2. Sai dep → memo stale. Dep là object mới mỗi lần → memo không bao giờ hit. useMemo là cache, không bảo đảm việc bị skip khi concurrent render.
3. Tương đương Vue: computed Vue là lazy và tự track. useMemo là cache, dep bạn tự liệt kê. Đừng dịch mọi computed thành useMemo.

// Suy ra lúc render, không cần useMemo
const total = items.reduce((s, it) => s + it.price, 0)

// Identity contract cho memo child / dep effect
const ids = useMemo(() => items.map((it) => it.id), [items])

// Không bao giờ hit: [] mới mỗi render là identity dep mới
const bad = useMemo(() => filter(items, opts), [{ sort }])

Điều gì xảy ra: total rẻ và đúng ngay lúc render. ids giữ cùng identity array khi items không đổi, nên child memo bail out được. { sort } làm dep là object mới mỗi lần, nên bad tính lại luôn: memo chỉ là hình thức.

Lỗi hay gặp

• Triệu chứng: mọi hằng bọc useMemo. Nguyên nhân: coi nó như computed. Cách xử lý: suy ra lúc render; memo chỉ khi chi phí đã chứng minh hoặc identity.
• Triệu chứng: child memo vẫn re-render. Nguyên nhân: dep là [] hoặc {} mới. Cách xử lý: memo giá trị đó, hoặc truyền primitive.
• Triệu chứng: filter cũ sau khi opts đổi. Nguyên nhân: thiếu dep. Cách xử lý: liệt kê field opts, không object mới.
• Triệu chứng: Compiler + memo tay đánh nhau. Nguyên nhân: policy “bọc hết”. Cách xử lý: đo, rồi xóa.

Tóm tắt: useCallback giữ identity của hàm ổn định khi identity đó là contract: memo child, dep của effect, value của context. Nó không làm thân hàm rẻ hơn. Vue hiếm khi cần vì child track data, không track identity onClick của parent.

Vì sao quan trọng: Mọi handler đều bọc useCallback “cho perf”, row đã memo vẫn re-render vì onClick là hàm mới, rồi người chuyên Vue hỏi sao Vue không bao giờ cần cái này. Vì sao identity hàm quan trọng trong React, và lúc nào useCallback chỉ là lãng phí?

1. Cách hoạt động: useCallback(fn, deps) trả cùng function reference khi deps vẫn bằng nhau theo Object.is. Hàm mới mỗi lần render làm memo fail (prop đổi) và effect nào liệt kê callback sẽ chạy lại.
2. Dep không ổn định (useCallback(() => do(x), []) với x cũ) là ship stale closure. Liệt kê setState thì ổn (React bảo đảm identity của nó). Liệt kê state khi bạn muốn liệt kê setState thì callback bị tạo lại mỗi lần.
3. Tương đương Vue: Child Vue tự track dep của chúng, nên identity onClick của parent hiếm khi quan trọng. memo của React so sánh function reference.

const Row = memo(function Row({ item, onSelect }: Props) {
  return <button onClick={() => onSelect(item.id)}>{item.name}</button>
})

function List({ items }: { items: Item[] }) {
  // ổn định khi items không đổi: Row bail out được
  const onSelect = useCallback((id: string) => {
    save(id)
  }, [])
  return items.map((item) => <Row key={item.id} item={item} onSelect={onSelect} />)
}

Điều gì xảy ra: Không có useCallback, onSelect là hàm mới mỗi lần List render, nên mọi Row đều fail memo dù item không đổi. Có nó thì identity giữ nguyên. Nếu save cần filter đang đổi, giá trị đó phải nằm trong list dep, không thì stale closure bị ship.

Lỗi hay gặp

• Triệu chứng: bọc mọi handler, chẳng nhanh hơn. Nguyên nhân: identity không phải contract. Cách xử lý: xóa đi; đo child đã memo.
• Triệu chứng: row memo vẫn re-render. Nguyên nhân: props khác (style={{}}) hoặc callback bắt state đang đổi trong closure với []. Cách xử lý: sửa deps, hoặc thôi bọc.
• Triệu chứng: filter cũ trong onSelect. Nguyên nhân: useCallback(..., []). Cách xử lý: liệt kê filter, hoặc đọc từ ref.
• Triệu chứng: Compiler + useCallback viết tay khắp nơi. Nguyên nhân: policy. Cách xử lý: chỉ giữ ở các lá memo.

Tóm tắt: useRef là hộp mutable { current } sống qua các lần render và không báo React. Nó không phải ref() của Vue. Template ref Vue (DOM / instance component) mới là thứ gần nhất. React 19 thì ref là prop bình thường, nên forwardRef thường không cần.

Vì sao quan trọng: Người chuyên Vue viết const count = useRef(0) như viết ref(0), rồi thắc mắc sao UI đứng im. Chỗ khác họ đọc ref.current lúc render để rẽ nhánh, và muốn lấy instance child như template ref.

1. Cách hoạt động: useRef(init) trả { current: init }. Gán .current không schedule một render. Đọc và ghi ref trong effect và handler, không lấy chúng làm nguồn output đã render.
2. DOM ref: ref={el} trên host node. React 19 thì function component nhận ref như prop; forwardRef vẫn cần cho cây cũ và một số library. useImperativeHandle expose một API instance nhỏ.
3. Tương đương Vue: ref() của Vue là state reactive → useState của React. Template ref Vue → useRef của React. Dịch ref(0) thành useRef(0) là cách UI đứng im.

function Field({ label }: { label: string }) {
  const inputRef = useRef<HTMLInputElement>(null)
  const count = useRef(0) // hộp: UI SẼ KHÔNG update
  const [n, setN] = useState(0) // state: UI sẽ update

  function focus() {
    inputRef.current?.focus() // handler: OK
    count.current += 1
  }
  // if (inputRef.current) ... lúc render là bẫy concurrent
  return <input ref={inputRef} aria-label={label} onFocus={focus} value={n} />
}

Điều gì xảy ra: Bấm focus thì caret chạy tới và count.current tăng, nhưng màn hình vẫn hiện n vì chỉ useState mới báo React. ref={inputRef} chính là tương đương template ref. Rẽ nhánh theo inputRef.current lúc render là race khi React concurrent.

Lỗi hay gặp

• Triệu chứng: UI đứng ở 0 sau count.current++. Nguyên nhân: dùng useRef như ref() của Vue. Cách xử lý: useState.
• Triệu chứng: hydration / tearing từ if (ref.current) lúc render. Nguyên nhân: render bị bỏ đã thấy node khác. Cách xử lý: đọc trong effect.
• Triệu chứng: child bỏ qua ref. Nguyên nhân: function component trước 19 không có forwardRef. Cách xử lý: nhận ref như prop (React 19) hoặc bọc.
• Triệu chứng: useImperativeHandle đổ cả store. Nguyên nhân: data biến thành API instance. Cách xử lý: props.

Tóm tắt: Nghĩ theo pha, không theo tên method của class. Render thì thuần. Commit áp DOM. Layout effects (useLayoutEffect) chạy trước paint. Passive effects (useEffect) chạy sau paint. Mount / update / unmount là lúc các effect đó chạy.

Vì sao quan trọng: Họ bảo bạn map componentDidMount sang Hooks, rồi tooltip nháy, useLayoutEffect + setHeight bị loop, và trang Next hydrate sai vì render gọi Date.now(). Vì sao render phải thuần, và khi nào useLayoutEffect mới là pha đúng?

1. Cách hoạt động: Render (thuần): nhận props/state/context, trả JSX. Không network, không setState, không ghi DOM. Concurrent React có thể render hai lần hoặc bỏ một render. Tính thuần là thứ giữ cho việc đó an toàn.
2. Commit áp mutation DOM. Rồi useLayoutEffect chạy trước khi browser paint: đo, hoặc diệt nháy. Rồi browser paint. Rồi useEffect chạy cho thế giới bên ngoài.
3. Unmount chạy cleanup cuối. Strict Mode lúc development remount một lần để chắc cleanup đúng.
4. Tương đương Vue: Vue đặt tên theo hook (onMounted, onUpdated, onBeforeUpdate). React đặt tên theo pha. onBeforeUpdate gần useLayoutEffect hơn; onMounted gần useEffect, chứ không phải tương đương.

function Tooltip({ text }: { text: string }) {
  const ref = useRef<HTMLDivElement>(null)
  const [h, setH] = useState(0)
  // layout: đo trước paint để tránh nháy
  useLayoutEffect(() => {
    const next = ref.current?.getBoundingClientRect().height ?? 0
    if (next !== h) setH(next) // guard: height trong deps, không có so sánh này thì loop
  }, [text, h])
  // render phải pure: không Date.now(), không Math.random()
  return <div ref={ref} style={{ top: h }}>{text}</div>
}

Điều gì xảy ra: Sau commit, layout effect đo node rồi, nếu cần, set height trước paint để tooltip không nháy ở top: 0. Guard next !== h chặn vòng layout→setState→layout. Bản thân render vẫn pure để hydration khớp.

Lỗi hay gặp

• Triệu chứng: tooltip nháy ở 0 rồi nhảy. Nguyên nhân: đo trong useEffect (sau paint). Cách xử lý: useLayoutEffect kèm guard.
• Triệu chứng: vòng layout vô hạn. Nguyên nhân: setHeight luôn ghi, height trong deps. Cách xử lý: chỉ ghi khi next !== h.
• Triệu chứng: lệch hydration trên Next. Nguyên nhân: Date.now() / Math.random() lúc render. Cách xử lý: render pure; đọc thời gian trong effect.
• Triệu chứng: INP tệ đi khi hover. Nguyên nhân: việc nặng trong useLayoutEffect. Cách xử lý: chỉ đo, tính sau.

Tóm tắt: Chọn nguồn sự thật và runtime. Document, SEO, secret: fetch trong async Server Component. Cache live phía client, filter, mutation xuyên island: TanStack Query. Fetch trong useEffect là fallback của SPA nhỏ, không phải mặc định của Next.

Vì sao quan trọng: Trang Next App Router fetch document trong useEffect, island bên cạnh cần cùng list kèm filter, rồi sau mutation không ai invalidate. TanStack Query, RSC, hay effect viết tay: data nằm ở đâu, hủy request đang chạy thế nào?

1. Cách hoạt động: fetch của RSC chạy trên server (bundle + secret không vào client) nhưng scoped theo request/cache, không phải cache live phía client. Waterfall xảy ra khi child chờ parent xong mới fetch được.
2. Query là cache client (stale-while-revalidate, key, invalidation). Sau POST, invalidateQueries. Race: ưu tiên cancel của Query, hoặc AbortController nếu bạn chịu trách nhiệm effect đó.
3. Tương đương Vue: useAsyncData / useFetch của Nuxt trong setup đóng vai trò giống RSC/payload. Pinia không phải HTTP cache. Cùng kiểu tách với Query khác Zustand.

// RSC: fetch document trên server (Next App Router)
export default async function Page({ params }: { params: { id: string } }) {
  const doc = await getDoc(params.id) // không useEffect
  return <Article doc={doc} />
}

// Island client: cache live + cancel qua Query
const { data } = useQuery({ queryKey: ['docs', filter], queryFn: fetchDocs })
// sau POST: queryClient.invalidateQueries({ queryKey: ['docs'] })

Điều gì xảy ra: HTML của document đã có doc, không cần fetch phía client. Island dùng cache Query theo key để filter và widget bên cạnh dùng chung row. Sau mutation bạn invalidate key đó, đừng lấy store.items.push làm nguồn sự thật. Fetch trong effect sẽ waterfall và race.

Lỗi hay gặp

• Triệu chứng: HTML trống, rồi mới fetch. Nguyên nhân: document load trong useEffect trên trang Next. Cách xử lý: async Server Component.
• Triệu chứng: hai island refetch cùng một list. Nguyên nhân: không có cache dùng chung. Cách xử lý: queryKey của Query, không phải hai effect.
• Triệu chứng: row còn stale sau PATCH. Nguyên nhân: không ai invalidate. Cách xử lý: invalidateQueries / revalidatePath.
• Triệu chứng: response cũ thắng. Nguyên nhân: fetch trong effect không abort. Cách xử lý: Query, hoặc AbortController trong cleanup.

Tóm tắt: Context là dependency injection cho giá trị ít đổi: theme, locale, user id, Query client. Đổi value của Provider thì re-render mọi consumer. memo trên consumer không skip được điều đó.

Vì sao quan trọng: App re-render mỗi lần gõ vì search nằm trong AppContext cạnh theme và user. Senior Vue nghĩ sẽ giống provide / inject, hỏi vì sao memo trên consumer không giúp, và Zustand có giúp không.

1. Cách hoạt động: createContext + Provider value={…} + use(Context) (React 19) hoặc useContext. Identity của value đổi thì báo mọi consumer, kể cả những consumer chỉ đọc theme.
2. Tách context (ThemeContext khác SearchContext) để một lần gõ không kéo chrome re-render. Hoặc để giá trị hay đổi trong Zustand / Jotai rồi subscribe theo selector.
3. Tương đương Vue: provide / inject track ref được inject. Child không đọc search thì không chạy lại. Context không có đồ thị như vậy.

const ThemeContext = createContext<Theme>('light')
const SearchContext = createContext('') // tách: đừng dùng chung với theme

function App() {
  const [q, setQ] = useState('')
  return (
    <ThemeContext value="dark">
      <SearchContext value={q}>
        <input value={q} onChange={(e) => setQ(e.target.value)} />
        <Results />
      </SearchContext>
    </ThemeContext>
  )
}

Điều gì xảy ra: Gõ chỉ update SearchContext. Consumer của ThemeContext không re-render. Nếu q nằm trên một AppContext phình to, mọi use(AppContext) sẽ re-render, memo(Results) cũng không giúp.

Lỗi hay gặp

• Triệu chứng: chrome re-render mỗi lần gõ search. Nguyên nhân: search cùng Context với theme. Cách xử lý: tách, hoặc Zustand.
• Triệu chứng: memo(Child) vẫn chạy. Nguyên nhân: Child gọi use(Context). Cách xử lý: đưa use vào wrapper nhỏ.
• Triệu chứng: mọi consumer re-render dù theme không đổi. Nguyên nhân: value={{ theme, user }} identity mới. Cách xử lý: memo hoặc hai provider.
• Triệu chứng: list user trong Context. Nguyên nhân: coi Context là cache. Cách xử lý: Query / RSC. Xem 20.2.7.

Tóm tắt: createPortal(child, domNode) vẽ child vào một node DOM khác. Event vẫn bubble theo cây React, không phải cây DOM. Click-outside dựa DOM thì kỳ vọng điều ngược lại.

Vì sao quan trọng: Modal bị overflow: hidden cắt. Bạn portal ra document.body. Click-outside trên parent stopPropagation không thấy click, và trang Next hydrate lệch vì server trả null còn client thì portal.

1. Cách hoạt động: Parent React giữ nguyên cho context, bắt lỗi, và bubble event. Parent DOM là domNode. CSS clipping/z-index theo parent DOM; stopPropagation trên DOM ancestor của trigger không thấy click từ portal.
2. SSR: target portal phải tồn tại trên server, không thì bạn render null đến lúc mount. Lệch như vậy thì hydrate sai. Ưu tiên #modal-root có sẵn trong HTML.
3. Tương đương Vue: <Teleport to="body"> cùng một ý tưởng product. Event Vue cũng theo cây Vue. Bẫy hydration vẫn vậy nếu server thiếu to.

function Modal({ children }: { children: React.ReactNode }) {
  const node = document.getElementById('modal-root')
  if (!node) return null // SSR: ưu tiên một node thật trong HTML
  return createPortal(
    <div role="dialog" className="modal">
      {children}
    </div>,
    node,
  )
}

Điều gì xảy ra: Dialog vẽ dưới #modal-root, thoát khỏi overflow: hidden. Click trên dialog vẫn bubble tới parent React của Modal, không tới DOM ancestor của #modal-root. Server trả null còn client trả dialog thì hydration lệch.

Lỗi hay gặp

• Triệu chứng: modal bị cắt. Nguyên nhân: vẽ trong overflow: hidden. Cách xử lý: portal ra body / #modal-root.
• Triệu chứng: click-outside không bao giờ chạy. Nguyên nhân: listener trên DOM ancestor; event đi lên cây React. Cách xử lý: lắng trên document.
• Triệu chứng: lệch hydration Next. Nguyên nhân: server null, client portal. Cách xử lý: node target thật trong HTML SSR.
• Triệu chứng: dropdown dưới modal bị đóng. Nguyên nhân: bubble React. Cách xử lý: stop trong handler React, không phải DOM.

Tóm tắt: <Suspense fallback={…}> là boundary UI loading cho children suspend (throw một thenable): code-split bằng lazy(), và data (use(), RSC, một số mode Query). Nó không phải error handler.

Vì sao quan trọng: Widget lazy() không có boundary thì throw lúc runtime. Fetch data fail rồi trang treo spinner vì không có Error Boundary. Vue <Suspense> “cảm giác giống”. Suspense bắt gì, đặt ở đâu, và Vue có cùng nghĩa không?

1. Cách hoạt động: Child suspend bằng cách throw một Promise. Suspense gần nhất hiện fallback đến khi Promise resolve, rồi retry cây. Cao quá → cả trang nháy. Thấp quá → spinner chồng lên nhau.
2. Lỗi throw ra như error (không phải thenable) thì cần Error Boundary. Lồng chúng: Error Boundary ngoài hoặc cạnh Suspense để lazy() import fail là lỗi, không phải fallback chạy mãi.
3. Tương đương Vue: Vue <Suspense> vẫn experimental và cover async setup. Nuxt thường thay bằng useAsyncData + pending. Đừng coi hai API là 1:1.

const Chart = lazy(() => import('./Chart'))

function Dashboard() {
  return (
    <ErrorBoundary fallback={<Failed />}>
      <Suspense fallback={<Spinner />}>
        <Chart />
      </Suspense>
    </ErrorBoundary>
  )
}

Điều gì xảy ra: Paint đầu hiện Spinner trong lúc Chart load. Import fail thì Error Boundary hiện Failed thay vì treo spinner. Không có Suspense, lazy() throw lúc runtime.

Lỗi hay gặp

• Triệu chứng: lazy() throw “crashed”. Nguyên nhân: không có Suspense phía trên. Cách xử lý: bọc bằng fallback.
• Triệu chứng: import fail treo spinner. Nguyên nhân: không có Error Boundary. Cách xử lý: lồng Error Boundary ngoài Suspense.
• Triệu chứng: cả trang nháy vì một widget nhỏ. Nguyên nhân: Suspense quá cao. Cách xử lý: hạ boundary xuống.
• Triệu chứng: coi Vue <Suspense> cùng API. Nguyên nhân: bản Vue experimental/async setup. Cách xử lý: nêu rõ khác biệt.

Tóm tắt: Error Boundary bắt lỗi render / lifecycle / constructor ở descendant. Chúng không bắt event handler, code async, hay render của chính boundary. Trong React 19 chúng vẫn là class (componentDidCatch).

Vì sao quan trọng: Tooltip throw làm white screen cả product vì boundary duy nhất nằm ở App. Họ hỏi sao cái này lại là class, có bắt lỗi fetch không, và reset thế nào sau khi user sửa state.

1. Cách hoạt động: Class implement getDerivedStateFromError và/hoặc componentDidCatch. Descendant throw lúc render thì React hiện UI this.state.hasError và báo lỗi. Production: react-error-boundary kèm Sentry.
2. Reset: đổi key trên boundary, hoặc gọi resetErrorBoundary() sau khi user thử lại. Đặt boundary mức widget để phần còn lại của trang vẫn sống.
3. Tương đương Vue: onErrorCaptured ở parent. Vue làm được trong function component. Core React thì không: tách một class ra.

class WidgetBoundary extends Component<{ children: React.ReactNode }, { err: Error | null }> {
  state = { err: null as Error | null }
  static getDerivedStateFromError(err: Error) {
    return { err } // render fallback
  }
  componentDidCatch(err: Error, info: React.ErrorInfo) {
    report(err, info) // Sentry: không bắt onClick hay fetch
  }
  render() {
    return this.state.err ? <Failed onRetry={() => this.setState({ err: null })} /> : this.props.children
  }
}

Điều gì xảy ra: Throw trong render của child thì hiện Failed. Throw trong onClick hoặc fetch().then thì không bị bắt: bạn vẫn cần try/catch ở đó. Retry xóa err để child mount lại.

Lỗi hay gặp

• Triệu chứng: một tooltip white screen tất cả. Nguyên nhân: chỉ có boundary App. Cách xử lý: boundary mức widget.
• Triệu chứng: “sao không bắt fetch của mình?” Nguyên nhân: async nằm ngoài render. Cách xử lý: Query isError, hoặc try/catch.
• Triệu chứng: retry không ăn. Nguyên nhân: render sau vẫn throw y như cũ. Cách xử lý: đổi data/key đã gây ra lỗi.
• Triệu chứng: function component “ErrorBoundary”. Nguyên nhân: Hook không implement được componentDidCatch. Cách xử lý: class wrapper.

Tóm tắt: Custom Hook là logic có state tái sử dụng, gọi Hook khác (useState, useEffect, Query). use* mà không gọi Hook là nói dối: linter tin cái tên. Composable Vue cùng bản năng extract, nhưng luật gọi tự do hơn.

Vì sao quan trọng: Có người prefix formatter thuần useFormatDate để trông “giống composable”, consumer gọi useUsers sau if (ready), và Hook fetch bằng useEffect trong khi app đã có Query.

1. Cách hoạt động: Extract cùng useDebouncedSearch(query) ở cả hai stack: giá trị đã debounce kèm lời gọi Query/useAsyncData. Trong React hàm phải được gọi không điều kiện ở đầu component hoặc Hook.
2. Nếu không gọi Hook, bỏ prefix use (formatDate). Nếu fetch, hãy gọi Query, đừng tự viết lại useEffect.
3. Tương đương Vue: Composable gọi trong if / vòng lặp tự do hơn (vẫn là smell). Rules of Hooks của React là then chốt vì list slot trên fiber. Cùng kiểu extract, chỗ gọi chặt hơn.

// Cùng kiểu extract như composable Vue; Rules of Hooks vẫn áp dụng
export function useDebouncedSearch(query: string) {
  const [q, setQ] = useState(query)
  useEffect(() => {
    const t = setTimeout(() => setQ(query), 200)
    return () => clearTimeout(t)
  }, [query])
  return useQuery({ queryKey: ['search', q], queryFn: () => search(q) })
}

// Sai tên: không có Hook bên trong
export function formatDate(d: Date) {
  return d.toISOString().slice(0, 10)
}

Điều gì xảy ra: useDebouncedSearch luôn gọi useState, useEffect, và useQuery đúng thứ tự đó. Consumer phải gọi ở đầu, không được gọi sau if (ready). formatDate là helper; prefix use sẽ làm linter bỏ qua chỗ gọi trái luật.

Lỗi hay gặp

• Triệu chứng: lỗi Rules-of-Hooks sau một lần toggle. Nguyên nhân: useUsers nằm sau if (ready). Cách xử lý: luôn gọi; bật Query với enabled: ready.
• Triệu chứng: useFormatDate gọi trong vòng lặp “chạy” đến khi ai đó thêm useState. Nguyên nhân: prefix use giả. Cách xử lý: đổi tên.
• Triệu chứng: fetch hai lần ở mọi màn. Nguyên nhân: Hook bọc useEffect(fetch). Cách xử lý: Query trong Hook.
• Triệu chứng: god Hook trả 20 field. Nguyên nhân: một composable cho cả trang. Cách xử lý: tách theo concern.

Tóm tắt: children là slot mặc định. Slot named và scoped thành header prop, compound component (Select.Item), hoặc hàm renderItem. Ưu tiên composition hơn mười hai boolean prop. Đừng cloneElement để giả scoped slot.

Vì sao quan trọng: <Button> có showIcon, showSpinner, isFullWidth, isDanger, asLink. Người chuyên Vue hỏi slot chạy thế nào, và một list inject props bằng cloneElement thì gãy trên Fragment.

1. Cách hoạt động: Nếu parent đã biết cấu trúc, nên truyền JSX (children hoặc header={<…>}). Compound component chia state ngầm qua Context. renderItem={(row) => …} tương đương scoped slot.
2. cloneElement để inject props gãy với Fragment, text node, và child đã memo. Ưu tiên props tường minh hoặc một render function.
3. Tương đương Vue: Slot mặc định → children. Slot named → một prop (header) hoặc <Card.Header>. Scoped slot → renderItem. Vue viết tiện hơn; React tường minh hơn.

// Composition thay vì mớ boolean
function Card({ children, header }: { children: React.ReactNode; header?: React.ReactNode }) {
  return (
    <section>
      {header}
      <div>{children}</div>
    </section>
  )
}

// Tương đương scoped slot
function List({ items, renderItem }: { items: Item[]; renderItem: (item: Item) => React.ReactNode }) {
  return <ul>{items.map((item) => <li key={item.id}>{renderItem(item)}</li>)}</ul>
}

Điều gì xảy ra: Parent truyền header bằng JSX, nên Card không phình thêm flag showHeaderIcon. renderItem nhận row: scoped slot mà không cần cloneElement. Fragment trong children chạy bình thường.

Lỗi hay gặp

• Triệu chứng: 12 boolean trên Button. Nguyên nhân: tránh dùng slot. Cách xử lý: truyền children / tách variant.
• Triệu chứng: cloneElement gãy với <>. Nguyên nhân: inject props vào child không biết trước. Cách xử lý: renderItem hoặc props tường minh.
• Triệu chứng: compound Select.Item dùng ngoài Select. Nguyên nhân: thiếu Context của parent. Cách xử lý: throw lỗi rõ.
• Triệu chứng: div bọc phá flex layout. Nguyên nhân: ép một node DOM quanh children. Cách xử lý: Fragment hoặc asChild.

Tóm tắt: Zustand là mặc định hình Pinia cho client UI. Redux Toolkit khi team cần quy ước hoặc đã dùng RTK Query. Jotai khi bài toán là đồ thị atomic. Không cái nào giữ list server: chỗ đó là Query hoặc RSC.

Vì sao quan trọng: “Redux hay Zustand?” xuất hiện trong vòng React, rồi đồng đội nhét list user vào slice “vì team dùng Redux”. Giữ câu trả lời ngắn: phần sâu nằm ở tài liệu state-management của React. Mặc định cho senior Vue là gì, và thứ gì không bao giờ được vào store?

1. Cách hoạt động: Zustand: create((set) => ({ count, inc })) kèm một selector. RTK: configureStore + các slice + RTK Query tùy chọn. Jotai: atom kèm useAtom ở leaf. Chọn theo hình team, không theo Twitter.
2. Tương đương Vue: Zustand ≈ Pinia (nhiều store nhỏ, compose lúc gọi). RTK ≈ Vuex kèm quy ước. Jotai ≈ nhiều ref nhỏ. Query ≈ useAsyncData. Đừng nhét row Product vào bất kỳ cái nào.

// Zustand: client UI hình Pinia
export const useCart = create<{ ids: string[]; add: (id: string) => void }>((set) => ({
  ids: [],
  add: (id) => set((s) => ({ ids: [...s.ids, id] })),
}))

// Jotai: một atom, subscribe ở leaf
export const idsAtom = atom<string[]>([])

// Đừng: list user trong Redux slice. Đó là Query / RSC.

Điều gì xảy ra: ids của cart nằm trong Zustand (state client kiểu session). Product detail lấy từ Query. Jotai cũng là ids đó nhưng dạng atom, nếu cây là đồ thị atomic. Slice users sẽ stale ngay lần admin sửa một row.

Lỗi hay gặp

• Triệu chứng: list admin stale. Nguyên nhân: user nằm trong slice Redux/Zustand. Cách xử lý: Query / RSC có key.
• Triệu chứng: “team dùng Redux” như kiến trúc. Nguyên nhân: không có tiêu chí. Cách xử lý: mặc định Zustand; RTK nếu đã có quy ước.
• Triệu chứng: Context + Zustand + Redux. Nguyên nhân: không có owner. Cách xử lý: một store client, Query cho server, Context cho DI.
• Triệu chứng: atom Jotai clone cây REST. Nguyên nhân: atom dùng như cache. Cách xử lý: Query.

Tóm tắt: Kiến trúc trước: state ở đâu, data server, bundle. Rồi mới tới Profiler. Folklore useMemo để cuối. Vue thường cảm giác đã tối ưu vì update fine-grained; senior React phải làm có chủ đích mới được cùng UX.

Vì sao quan trọng: “Làm trang này nhanh hơn thế nào?” Junior rải useMemo, bỏ Profiler, ship bảng 5k row, rồi fetch waterfall ở parent. Vue thì cảm giác “đã tối ưu sẵn”. Bạn đo gì trước, và lever nào là kiến trúc, lever nào là folklore?

1. Cách hoạt động: Đo bằng React Profiler và một Performance trace (INP, long task). Nêu rõ bottleneck: network, JS, render, hoặc layout.
2. Locality của state: input ở leaf không được re-render dashboard. List server để trong Query/RSC, không phải store. Key trên list. Virtualize 5k row.
3. Bundle: tách theo route, lazy chart. Transition cho list không gấp. Compiler nếu org đã bật. useMemo chỉ khi Profiler đã chứng minh.
4. Tương đương Vue: Đồ thị của Vue đã skip việc không dùng. React bắt bạn đặt state, key, và split bằng tay, hoặc bật Compiler.

// Profiler trước. Rồi locality. Rồi memo.
function Page() {
  const { data } = useQuery({ queryKey: ['rows'], queryFn: fetchRows })
  return (
    <>
      <SearchBox /> {/* state riêng: không được rerender table */}
      <VirtualTable rows={data ?? []} />
    </>
  )
}

Điều gì xảy ra: State search ở lại SearchBox, nên gõ không dựng lại 5k row. Row đến từ Query, không phải Zustand. Table thì virtualize. useMemo không có trong file cho đến khi Profiler nói mapper của row đang nóng.

Lỗi hay gặp

• Triệu chứng: “thêm useMemo khắp nơi, vẫn chậm”. Nguyên nhân: chưa từng profile. Cách xử lý: Profiler, rồi một lever.
• Triệu chứng: gõ làm dashboard giật. Nguyên nhân: state search lift quá cao. Cách xử lý: locality, không phải memo.
• Triệu chứng: 5k <tr> trong DOM. Nguyên nhân: không windowing. Cách xử lý: virtualize.
• Triệu chứng: waterfall ở parent. Nguyên nhân: child chờ JSON của parent. Cách xử lý: fetch song song / RSC.

Tóm tắt: React SPA không có Edge middleware. RequireAuth kèm <Outlet /> là cổng UX sau khi JS load. Loader của React Router gần beforeEnter hơn, và vẫn chạy sau request. Next middleware.ts chạy trên Edge trước HTML: cookie, không phải RBAC.

Vì sao quan trọng: Người chuyên Vue/Nuxt lập tức lôi beforeEach / middleware/ ra và viết <Navigate to="/login" /> ngay lúc user là null. Trang login nháy, /login nằm cùng matcher “có cookie” với /app, và họ gọi đó là security.

1. Cách hoạt động: SPA: bọc route cần bảo vệ trong layout đọc session rồi <Navigate>. Nó chạy sau bundle. Loader/action có thể redirect sớm hơn trong lifecycle SPA, vẫn trên client trừ khi bạn SSR.
2. Next middleware.ts: có cookie, geo, A/B, redirect: trước HTML. Authorization nằm ở API / RSC / server. Matcher /login với “có cookie” thì loop.
3. Tương đương Vue: Vue Router beforeEach ≈ wrapper/loader SPA. Route middleware của Nuxt chạy được cả server và client. Server middleware Nuxt/Nitro ≈ Edge middleware của Next. Không cái nào là source of truth của authz.

function RequireAuth() {
  const { user, ready } = useSession()
  if (!ready) return <Splash /> // tránh nháy login
  if (!user) return <Navigate to="/login" replace />
  return <Outlet />
}

// Next middleware.ts: cổng cookie TRƯỚC html, không phải RBAC
// if (!req.cookies.has('sid') && !req.nextUrl.pathname.startsWith('/login')) redirect

Điều gì xảy ra: ready tránh nháy /login lúc session đang hydrate. User chưa auth thì replace sang /login. Cổng cookie của Next chạy trước HTML và phải loại /login, không thì loop. Không check nào thay được 401 của API.

Lỗi hay gặp

• Triệu chứng: trang login nháy. Nguyên nhân: <Navigate> khi session còn null. Cách xử lý: cổng ready hoặc loader.
• Triệu chứng: redirect loop trên /login. Nguyên nhân: matcher middleware gồm luôn login. Cách xử lý: loại nó ra.
• Triệu chứng: “đã bảo vệ xong route”. Nguyên nhân: chỉ wrapper phía client. Cách xử lý: API/RSC vẫn phải authorize.
• Triệu chứng: gọi Navigate SPA là “middleware”. Nguyên nhân: từ vựng Vue. Cách xử lý: gọi đúng là cổng UX.

Tóm tắt: Concurrent React ngắt được một render để update khẩn (lúc gõ) không bị cây nặng chặn. startTransition đánh dấu setState không khẩn. useDeferredValue giữ value khẩn gần nhất cho child đắt. Chúng hạ ưu tiên việc; không làm cây O(n²) rẻ.

Vì sao quan trọng: Gõ vào filter thì input bị trễ vì list 20k row re-render trên cùng một update khẩn. Có người bọc mọi setState trong startTransition, người khác dùng useDeferredValue như debounce, rồi hỏi cái này có thay memo không.

1. Cách hoạt động: Update khẩn (input) render ngay. Update transition (list) có thể bị ngắt nếu update khẩn mới tới. Input vẫn mượt; list bắt kịp sau.
2. startTransition(() => setFilter(q)) bọc setState nặng. useDeferredValue(q) truyền q deferred vào child đắt, còn input thì controlled bởi q khẩn.
3. Đây không phải debounce (bạn không bỏ việc). Đây không phải memo (bạn vẫn render; chỉ schedule sau). Fiber mới cho phép render ngắt được. Xem 20.1.1.
4. Tương đương Vue: Đồ thị fine-grained của Vue thường giữ input rẻ mà không cần API. React 19 cần bạn đánh dấu phần không khẩn. Không có startTransition 1:1 bên Vue.

function FilterList({ rows }: { rows: Row[] }) {
  const [q, setQ] = useState('')
  const deferred = useDeferredValue(q) // list trễ; input thì không
  return (
    <>
      <input value={q} onChange={(e) => setQ(e.target.value)} />
      <HeavyList rows={rows} filter={deferred} />
    </>
  )
}

Điều gì xảy ra: Mỗi lần gõ thì update q khẩn, nên caret không trễ. HeavyList nhận deferred, lúc đó có thể vẫn là chuỗi trước, khi React chưa xong lần render list vừa rồi. Nếu state nặng tách khỏi input, hãy bọc setFilter trong startTransition.

Lỗi hay gặp

• Triệu chứng: input vẫn lag. Nguyên nhân: startTransition bọc setState của input. Cách xử lý: bọc state của list, hoặc useDeferredValue trên child.
• Triệu chứng: “giờ không cần virtualize”. Nguyên nhân: coi transition như vé miễn phí cho 20k row. Cách xử lý: vẫn phải virtualize.
• Triệu chứng: dùng useDeferredValue như debounce. Nguyên nhân: kỳ vọng các lần gõ bị bỏ. Cách xử lý: debounce network; defer render.
• Triệu chứng: mọi setState nằm trong transition. Nguyên nhân: policy. Cách xử lý: chỉ cái đắt.

Tóm tắt: Bản map Vue → React cho phỏng vấn React 19. Đọc sau 20.1–20.2. Các hàng dễ trượt là ref ≠ useRef, watch ≠ useEffect, và Pinia ≠ REST cache.

Vì sao quan trọng: Người phỏng vấn bảo bạn diễn một phản xạ Vue trong một câu. Cheat sheet chính là câu đó theo từng hàng, rồi họ hỏi xoáy topic phía sau hàng.

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 bẫy của hàng đó (ví dụ useRef không phải ref()).
2. Đừng thuộc lòng cả bảng. Chọn hàng họ hỏi rồi mở topic 20.1 / 20.2 khớp.

Lỗi hay gặp

• Triệu chứng: UI đứng im sau useRef(0). Nguyên nhân: map ref() của Vue. Cách xử lý: useState. Xem 20.1.10.
• Triệu chứng: fetch trong useEffect “vì onMounted”. Nguyên nhân: map lifecycle 1:1. Cách xử lý: Query / RSC. Xem 20.1.12.
• Triệu chứng: list user trong Zustand. Nguyên nhân: map Pinia như REST cache. Cách xử lý: Query. Xem 20.2.7.
• Triệu chứng: đọc thuộc cả 13 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.