Temu Duga Frontend: Bagaimana Anda Menyahpepijat dan Membetulkan Penutupan Lapuk (Stale Closures) dalam React?

Masalah dan Konteks yang Berkenaan

Pertimbangkan papan pemuka React 19.2 yang melanggan pesanan langsung:

function LiveOrders({ tenantId }: { tenantId: string }) {
  const [filter, setFilter] = useState("all")
  const [count, setCount] = useState(0)

  useEffect(() => {
    const connection = connect(tenantId)

    connection.on("order", (order) => {
      if (matches(order, filter)) {
        setCount(count + 1)
      }
    })

    return () => connection.close()
  }, [])

  // Rendering and controls omitted.
}

Selepas pengguna menukar penapis, panggilan balik masih menggunakan "all". Beberapa pesanan dalam satu letusan mungkin meninggalkan kiraan pada 1. Jika komponen menerima tenantId yang berbeza, ia kekal disambungkan kepada penyewa pertama. Menambahkan setiap nilai yang dirujuk ke dalam senarai kebergantungan nampaknya membetulkan kesegaran, tetapi kemudian setiap perubahan kiraan atau penapis akan menutup dan mencipta semula sambungan.

Terangkan mengapa kegagalan ini berlaku, bagaimana untuk membuktikan nilai mana yang lapuk, dan bagaimana untuk mengekalkan jangka hayat langganan yang dimaksudkan sementara panggilan balik memerhatikan nilai terkomit yang terkini.

Ini adalah soalan temu duga frontend yang realistik kerana panduan temu duga React awam dalam kedua-dua bahasa Inggeris dan bahasa Cina secara eksplisit menguji penutupan lapuk, peraturan Hook, dan kebergantungan useEffect. Kemahiran yang lebih mendalam bukanlah menghafal satu penyelesaian sementara. Ia adalah memutuskan sama ada sesuatu nilai patut memulakan semula Kesan, mengambil bahagian dalam peralihan keadaan, atau dibaca secara bukan reaktif oleh panggilan balik yang dimiliki oleh Kesan.

Perkara yang Dinilai oleh Penemu Duga

Pertama, bolehkah calon menerangkan mekanismenya dengan tepat? Setiap pemaparan menerima tangkapan skrin props dan keadaan. Fungsi yang dicipta semasa pemaparan tersebut merangkumi tangkapan skrin itu. React tidak mengubah pemboleh ubah tempatan filter, count, atau tenantId selepas pemaparan terkemudian. Jika sistem luaran mengekalkan panggilan balik pertama, panggilan balik tersebut terus membaca nilai pemaparan pertama. Penutupan berkelakuan seperti biasa; kontrak penyegerakan yang diisytiharkan oleh Kesan adalah tidak lengkap.

Kedua, bolehkah calon memisahkan empat keperluan berbeza?

Ketiga, bolehkah calon menolak penyelesaian palsu? useCallback(fn, []) mengekalkan identiti fungsi tetapi juga mengekalkan penutupan pemaparan pertamanya. Menyembunyikan exhaustive-deps menyembunyikan bukti dan bukannya mengubah semantik. Mencipta semula WebSocket untuk setiap peningkatan pembilang mungkin segar tetapi merupakan jangka hayat sumber yang salah.

Akhir sekali, bolehkah calon merangkumi pembersihan dan susunan tak segerak? Penutupan yang segar tidak membatalkan permintaan lama, menghalang respons yang tidak mengikut susunan, atau membuang pendengar peristiwa yang bocor. Itu adalah kewajipan keserentakan dan kitaran hayat yang berasingan.

Soalan Penjelasan Sebelum Menjawab

• Nilai manakah yang mentakrifkan identiti langganan? Jika tenantId memilih strim

sebelah pelayan, menukarnya mesti menyambung semula. Penapis paparan biasanya tidak patut menyambung semula.

• Patutkah peristiwa sejarah dinilai semula apabila penapis bertukar? Ini menentukan sama ada

penapis hanya tergolong dalam panggilan balik atau turut mencetuskan pertanyaan atau langganan baharu.

• Adakah panggilan balik mengira daripada keadaan sebelumnya? Menaikkan kiraan harus menggunakan

pengemas kini fungsi walaupun panggilan balik membaca nilai segar sebaliknya.

• Versi React manakah yang digunakan? useEffectEvent tersedia dalam React 19.2. Pada versi

yang lebih lama, ref yang disegerakkan dengan teliti mungkin menjadi alternatif keserasian.

• Bolehkah API luaran menggantikan pendengarnya tanpa menyambung semula? Sesetengah pustaka mendedahkan

operasi subscribe dan updateHandler yang berasingan, yang mungkin menyokong jangka hayat minimum yang berbeza.

• Adakah permintaan tak segerak dimulakan oleh panggilan balik? Jika ya, takrifkan pembatalan atau

semakan generasi permintaan selain menyelesaikan nilai yang ditangkap.

• Adakah Mod Ketat didayakan dalam pembangunan? Kitaran persediaan dan pembersihan tambahannya boleh mendedahkan

pembersihan yang hilang, tetapi ia tidak mencipta penutupan lapuk.

Kerangka Jawapan 30 Saat

“Panggilan balik React membaca tangkapan skrin props dan keadaan daripada pemaparan yang menciptanya. Di sini Kesan hanya berjalan sekali, jadi sambungan mengekalkan penyewa, penapis, dan kiraan pertama. Saya akan menjadikan langganan bergantung pada tenantId, kerana nilai tersebut mengubah sumber yang kita sambungkan. Saya akan mengemas kini kiraan dengan setCount(current => current + 1), kerana ia diperoleh daripada keadaan sebelumnya. Untuk panggilan balik pesanan membaca penapis terkini tanpa menyambung semula, pada React 19.2 saya akan meletakkan logik bukan reaktif itu dalam useEffectEvent dan memanggilnya daripada pendengar milik Kesan. Saya tidak akan menyembunyikan linter kebergantungan atau menggunakan useCallback([]) sebagai pembaikan kesegaran. Ref ialah pilihan keserasian manual untuk data boleh ubah yang tidak dipaparkan, dan hasil tak segerak masih memerlukan pembatalan atau versi.”

Penyelaman Mendalam Langkah Demi Langkah

Langkah satu: modelkan setiap pemaparan sebagai tangkapan skrin yang tidak boleh diubah (immutable).

Semasa pemaparan pertama, anggap nilai-nilai ini adalah:

tenantId = "tenant-a"
filter = "all"
count = 0

Kesan mencipta sambungan dan panggilan balik yang merujuk tepat kepada pemboleh ubah tempatan tersebut. Kemudian, setFilter("paid") menghasilkan pemaparan lain dengan pemboleh ubah filter baharu. Ia tidak menyunting pemboleh ubah yang ditangkap oleh panggilan balik asal. Kerana senarai kebergantungan kosong menyatakan bahawa Kesan tidak perlu disegerakkan lagi, sambungan luaran terus memiliki panggilan balik asal.

Itu meramalkan ketiga-tiga pepijat tanpa meneka:

1. matches(order, filter) terus menggunakan "all".
2. Setiap peristiwa yang sepadan memanggil setCount(0 + 1), jadi peristiwa berulang menggantikan keadaan dengan 1 berbanding

menggubah kenaikan.

1. Sambungan kekal dikaitkan dengan "tenant-a" selepas pertukaran prop.

Log penyahpepijatan yang berguna merangkumi nombor jujukan pemaparan, nilai yang dilihat semasa pemaparan, dan nilai yang dilihat di dalam panggilan balik yang dikekalkan. Log ID sambungan secara berasingan. Ini mendedahkan sama ada panggilan balik adalah lapuk, langganan tidak dimulakan semula, atau pelayan menghantar data yang tidak dijangka.

Langkah dua: kelaskan setiap bacaan mengikut semantik sebelum menyunting kebergantungan.

Tanya mengapa Kesan membaca setiap nilai:

• tenantId menentukan strim luaran mana yang disegerakkan. Ia adalah reaktif dan tergolong dalam

senarai kebergantungan.

• count hanya diperlukan untuk mengira kiraan seterusnya. Gantikan bacaan dengan pengemas kini fungsi,

supaya ia tidak lagi perlu ditangkap.

• filter mempengaruhi cara peristiwa masa hadapan dikendalikan, tetapi menukarnya tidak sepatutnya meruntuhkan sambungan

penyewa. Pendengar memerlukan bacaan nilai terkini tanpa menjadikan langganan reaktif kepada penapis.

Pengelasan ini menghalang dua keadaan melampau: senarai kebergantungan kosong dan senarai kebergantungan yang memulakan semula sumber yang mahal pada setiap perubahan berkaitan pemaparan.

Langkah tiga: betulkan peralihan keadaan dengan pengemas kini fungsi.

Tukar ini:

setCount(count + 1)

kepada ini:

setCount((current) => current + 1)

React meletakkan pengemas kini dalam giliran dan menghantar keadaan semasa yang belum selesai kepadanya apabila pemaparan seterusnya dikira. Sepuluh peristiwa oleh itu menggabungkan sepuluh kenaikan walaupun panggilan balik didaftarkan lebih awal atau React menggabungkan kemas kini. Ini hanya membetulkan kebergantungan count. Ia tidak menjadikan filter atau tenantId segar.

Langkah empat: isytiharkan kebergantungan yang benar-benar menyegerakkan semula sumber.

Identiti sambungan merangkumi tenantId, jadi Kesan mesti bergantung padanya. Pada pertukaran penyewa, React terlebih dahulu menjalankan pembersihan sebelumnya dan kemudian menyediakan sambungan baharu. Pembersihan mesti membuang pendengar atau menutup sambungan lama supaya peristiwa daripada penyewa sebelumnya tidak boleh mengemas kini skrin semasa.

Menambah filter dan count secara teknikal akan memberikan setiap panggilan balik baharu nilai semasa, tetapi ia juga akan mentakrifkan semula jangka hayat sambungan. Kemas kini pembilang akan menyebabkan pemutusan dan penyambungan semula. Itu boleh kehilangan peristiwa, menduplikasi peristiwa semasa pembersihan bertindih, menetapkan semula keadaan kursor sebelah pelayan, dan mencipta beban yang tidak perlu. Senarai kebergantungan ialah spesifikasi tingkah laku, bukan petunjuk prestasi untuk disunting sehingga linter menjadi senyap.

Langkah lima: gunakan Effect Event untuk bacaan bukan reaktif terkini dalam React 19.2.

Komponen yang dibetulkan boleh memastikan jangka hayat sambungan dan kesegaran panggilan balik dipisahkan:

function LiveOrders({ tenantId }: { tenantId: string }) {
  const [filter, setFilter] = useState("all")
  const [count, setCount] = useState(0)

  const onOrder = useEffectEvent((order: Order) => {
    if (matches(order, filter)) {
      setCount((current) => current + 1)
    }
  })

  useEffect(() => {
    const connection = connect(tenantId)
    connection.on("order", onOrder)

    return () => connection.close()
  }, [tenantId])

  // Rendering and controls omitted.
}

onOrder sentiasa memerhatikan filter terkomit terkini, manakala Kesan masih menyegerak semula hanya apabila tenantId berubah. Effect Event dipanggil daripada Kesan atau kod yang disambungkan kepada Kesan tersebut, seperti pendengar yang didaftarkannya. Ia bukan pengganti pengendali peristiwa umum, tidak sepatutnya dihantar sewenang-wenangnya melalui pepohon komponen, dan tidak boleh digunakan untuk menyembunyikan nilai yang sepatutnya memulakan semula penyegerakan.

Jangan tambah Effect Event ke senarai kebergantungan. Penganalisisan lint React semasa memahami peranan bukan reaktifnya. Jika linter melaporkan nilai yang berbeza, anggap amaran itu sebagai maklum balas reka bentuk dan tukar struktur kod daripada melumpuhkan peraturan tersebut.

Langkah enam: fahami bila ref sesuai dan apa kosnya.

Sebelum React 19.2, corak keserasian biasa menyimpan nilai terkini dalam ref:

const filterRef = useRef(filter)

useEffect(() => {
  filterRef.current = filter
}, [filter])

useEffect(() => {
  const connection = connect(tenantId)
  connection.on("order", (order) => {
    if (matches(order, filterRef.current)) {
      setCount((current) => current + 1)
    }
  })

  return () => connection.close()
}, [tenantId])

Objek ref adalah stabil merentasi pemaparan, dan menukar current tidak mencetuskan pemaparan. Itu menjadikan ref sesuai untuk nilai imperatif seperti pengendali terkini, ID pemasa, atau pemegang API luaran yang tidak dipaparkan. Kosnya ialah penyegerakan manual: linter kebergantungan tidak dapat membuktikan bahawa filterRef.current dikemas kini dengan betul, dan Kesan penyegerakan yang hilang secara senyap memperkenalkan semula tingkah laku lapuk. Jangan pindahkan keadaan yang dipaparkan ke dalam ref semata-mata untuk mengelakkan pemaparan, dan jangan baca atau tulis ref semasa pemaparan kecuali untuk corak permulaan yang didokumenkan.

Langkah tujuh: kekalkan useCallback dan pememoan dalam peranan yang sepatutnya.

useCallback menyimpan cache identiti fungsi sehingga salah satu kebergantungannya berubah. Ia berguna apabila anak yang dimemokan atau API luaran mementingkan identiti. Ia tidak menyediakan nilai terkini dengan sendirinya:

const onOrder = useCallback((order: Order) => {
  if (matches(order, filter)) {
    setCount((current) => current + 1)
  }
}, [])

Versi ini masih menangkap penapis awal. Menambah [filter] menyegarkan fungsi, tetapi sambungan luaran mesti menggantikan pendengarnya dengan betul. Jika penyingkiran pendengar memerlukan identiti fungsi yang sama, persediaan dan pembersihan mesti menggunakan contoh panggilan balik yang sama untuk pemaparan itu. Pememoan menjawab soalan identiti; ia tidak menjawab soalan jangka hayat penyegerakan.

Langkah lapan: selesaikan susunan tak segerak secara berasingan.

Katakan penapis terkini memulakan permintaan. Permintaan "all" mungkin diselesaikan selepas permintaan "paid" yang lebih baharu dan menulis ganti hasilnya. Malah panggilan balik dengan penapis terkini tidak dapat menghalang permintaan lama itu daripada selesai. Kesan harus membatalkan kerja usang dengan AbortController apabila disokong, atau mengaitkan setiap permintaan dengan generasi yang meningkat secara monoton dan mengkomit hanya generasi terkini.

Pembersihan juga mestilah simetri:

• tutup sambungan tepat yang dicipta oleh persediaan itu;
• buang pendengar tepat yang didaftarkan oleh persediaan itu;
• kosongkan selang dan tamat masa;
• batalkan atau tidak sahkan kerja tak segerak yang belum selesai;
• jadikan panggilan balik lewat tidak berbahaya selepas pembersihan.

Jujukan persediaan-pembersihan-persediaan Mod Ketat untuk pembangunan sahaja adalah bukti yang berguna di sini. Sambungan pendua menunjukkan pembersihan yang tidak lengkap. Ia bukan bukti bahawa Mod Ketat menyebabkan penutupan lapuk.

Langkah sembilan: sahkan tingkah laku dengan menukar satu dimensi pada satu masa.

Dalam pengeluaran, jejak kiraan persediaan dan pembersihan sambungan, ID sambungan aktif, pertukaran penyewa, peristiwa lewat yang digugurkan, dan permintaan yang dibatalkan. Jangan log muatan pesanan peribadi semata-mata untuk mendiagnosis kesegaran panggilan balik.

Contoh Jawapan Berkualiti Tinggi

“Saya akan bermula daripada model pemaparan React. Setiap pemaparan mendapat tangkapan skrin props dan keadaan, dan fungsi yang dicipta dalam pemaparan tersebut merangkumi tangkapan skrin itu. Kerana Kesan ini mempunyai senarai kebergantungan kosong, sambungan luaran mengekalkan panggilan balik daripada pemaparan pertama. Oleh itu, ia melihat penyewa, penapis, dan kiraan pertama.

Saya akan mengelaskan setiap nilai sebelum menukar senarai kebergantungan. tenantId memilih sumber luaran, jadi ia tergolong dalam kebergantungan dan pertukaran mesti menutup sambungan lama dan membuka sambungan baharu. count hanya digunakan untuk memperoleh keadaan seterusnya, jadi saya akan memanggil setCount(current => current + 1). Itu membuatkan kemas kini letusan bergabung daripada keadaan beratur React. filter terkini diperlukan apabila pendengar pesanan milik Kesan dicetuskan, tetapi ia tidak sepatutnya memulakan semula sambungan. Memandangkan aplikasi ini menggunakan React 19.2, saya akan meletakkan logik penapisan dalam useEffectEvent dan mendaftarkan Effect Event tersebut daripada Kesan yang hanya bergantung pada tenantId.

Saya tidak akan menyembunyikan exhaustive-deps, kerana senarai kebergantungan menerangkan penyegerakan. Saya tidak akan menggunakan useCallback([]) sebagai pembaikan kesegaran, kerana ia mengekalkan penutupan awal. Pada versi React yang lebih lama, ref yang disegerakkan daripada filter boleh menjadi alternatif keserasian, tetapi itu adalah manual dan tidak kelihatan kepada analisis kebergantungan.

Akhir sekali, saya akan menguji peningkatan letusan, pertukaran penapis tanpa menyambung semula, pertukaran penyewa dengan tepat satu pembersihan dan persediaan, peristiwa yang tiba daripada sambungan yang ditutup, dan Mod Ketat pembangunan. Jika panggilan balik melancarkan permintaan, saya juga akan membatalkan atau menetapkan versi permintaan yang usang, kerana kesegaran penutupan sahaja tidak menghalang hasil yang tidak mengikut susunan.”

Kesilapan Lazim

• Memanggil setiap penutupan sebagai pepijat → panggilan balik sememangnya dijangka menangkap tangkapan skrin pemaparan →

kenal pasti ketidakpadanan antara panggilan balik yang dikekalkan dan penyegerakan yang dimaksudkan.

• Menyembunyikan exhaustive-deps → kod menjanjikan bahawa bacaan reaktif tidak penting sedangkan

ia masih menggunakannya → ubah kod supaya senarai kebergantungan menerangkan Kesan secara jujur.

• Menambah setiap nilai keadaan ke kebergantungan → kesegaran dipulihkan dengan mencipta semula langganan yang mahal

selepas setiap kemas kini → asingkan identiti sumber daripada bacaan panggilan balik terkini.

• Menggunakan useCallback(fn, []) → identiti yang stabil juga membekukan penutupan pertama → **berikan

useCallback kebergantungan yang betul atau gunakan alat yang sepadan dengan semantik yang diingini.**

• Menggantikan keadaan dengan ref → penulisan ref tidak menghasilkan pemaparan dan boleh menyimpang daripada UI yang kelihatan →

kekalkan data yang dipaparkan dalam keadaan dan khaskan ref untuk data boleh ubah imperatif.

• Menggunakan useEffectEvent untuk menyembunyikan kebergantungan sebenar → Kesan tidak lagi bertindak balas apabila

sumber luarannya sepatutnya berubah → kekalkan nilai yang mentakrifkan sumber dalam senarai kebergantungan.

• Membetulkan penapis tetapi mengekalkan setCount(count + 1) → peristiwa letusan masih menggantikan daripada

kiraan yang ditangkap → gunakan pengemas kini fungsi untuk keadaan yang diperoleh daripada keadaan sebelumnya.

• Mengabaikan pembersihan dan susunan permintaan → pendengar yang bocor dan respons lewat masih merosakkan

skrin → buang, tutup, batalkan, atau tetapkan versi setiap operasi mengikut kitaran hayatnya.

Soalan Susulan dan Respons

Susulan 1: Mengapakah setTimeout di dalam pengendali klik melihat nilai keadaan yang lama?

Panggilan balik tamat masa tergolong dalam pemaparan tempat klik itu berlaku. Mengemas kini keadaan menjadualkan pemaparan baharu; ia tidak mengubah pemboleh ubah keadaan tempatan pengendali itu. Jika tindakan tertunda sepatutnya melaporkan nilai pada masa klik, tangkapan skrin itu betul. Jika ia mesti menggunakan nilai terkomit terkini, modelkan keperluan itu secara eksplisit dengan Effect Event dalam kod berkaitan Kesan atau ref yang diselenggara dengan teliti untuk panggilan balik imperatif.

Susulan 2: Mengapa tidak meletakkan filter dalam senarai kebergantungan Kesan?

Itu betul hanya jika menukar penapis sepatutnya menyegerakkan semula sistem luaran. Jika langganan pelayan itu sendiri khusus untuk penapis, sertakannya dan sambung semula. Dalam senario ini strim penyewa kekal sama dan penapis ialah dasar pemprosesan peristiwa tempatan, jadi menyambung semula akan memberikan jangka hayat yang salah. Nyatakan andaian produk dan API sebelum memilih.

Susulan 3: Adakah useEffectEvent menggantikan pengendali peristiwa biasa?

Tidak. Klik butang biasanya dikendalikan oleh pengendali peristiwa yang dicipta semasa pemaparan. Effect Event adalah untuk logik bukan reaktif yang dipanggil oleh Kesan atau kod yang disambungkan kepadanya, seperti pemasa atau pendengar langganan. Ia harus kekal tempatan kepada Kesan yang menggunakannya dan tidak sepatutnya menjadi mekanisme penghantaran panggilan balik umum.

Susulan 4: Bolehkah pengemas kini fungsi menyelesaikan setiap penutupan lapuk?

Tidak. Ia hanya menyelesaikan peralihan keadaan yang diperoleh daripada nilai sebelumnya bagi keadaan yang sama itu. Ia tidak boleh menjadikan prop, pemboleh ubah keadaan lain, atau konfigurasi luaran sebagai terkini. Dalam contoh ini ia membetulkan kenaikan kiraan tetapi bukan sambungan penyewa atau bacaan penapis.

Susulan 5: Bilakah ref lebih diutamakan berbanding keadaan?

Gunakan ref apabila nilai mesti kekal merentasi pemaparan, perubahan tidak sepatutnya memaparkan semula UI, dan nilai tersebut digunakan secara imperatif: ID pemasa, nod DOM, pemegang sambungan, atau sel nilai terkini keserasian. Jika output yang dipaparkan bergantung padanya, gunakan keadaan. Ref mengalihkan tanggungjawab kesegaran kepada pembangun, jadi dokumentasikan dan uji titik penyegerakannya.

Susulan 6: Bagaimanakah Mod Ketat boleh membantu menyahpepijat isu ini?

Mod Ketat pembangunan menjalankan kitaran persediaan dan pembersihan tambahan untuk Kesan. Jika dua pendengar atau sambungan kekal, pembersihan tidak lengkap atau menggunakan identiti panggilan balik yang salah. Sebaik sahaja pembersihan betul, kitaran tambahan itu harus meninggalkan satu langganan aktif. Tangkapan skrin lapuk itu sendiri mengikut semantik penutupan JavaScript biasa dalam kedua-dua mod.

Susulan 7: Bagaimana jika sesuatu peristiwa dicetuskan antara pembersihan dan sambungan baharu?

Takrifkan jaminan penghantaran sistem luaran. Klien mungkin memerlukan kursor yang boleh disambung semula, nombor jujukan, tetingkap main semula, atau tangkapan skrin diikuti dengan strim. Perubahan kebergantungan React boleh menguruskan jangka hayat tempatan, tetapi ia tidak dapat menjamin penghantaran tanpa kehilangan merentasi penyambungan semula pelayan. Itu adalah keperluan protokol dan harus diuji secara berasingan.

Susulan 8: Bagaimana anda menghalang pengambilan (fetch) yang lebih lama daripada menulis ganti hasil yang lebih baharu?

Batalkan permintaan usang semasa pembersihan Kesan apabila API menyokong pembatalan. Jika tidak, tetapkan generasi kepada setiap permintaan dan kemas kini keadaan hanya apabila generasi yang sedang selesai masih semasa. Ref nilai terkini sahaja tidak membatalkan kerja rangkaian dan tidak sepatutnya dibentangkan sebagai jaminan susunan.