Wawancara Frontend: Merancang Shadow DOM deklaratif dengan progressive hydration

Perintah dan cakupan

Halaman ini melakukan streaming kartu produk dari server. Setiap kartu harus me-render konten yang bermakna tanpa JavaScript, menjaga gaya komponen tetap terisolasi, dan melampirkan perilaku saat bundle klien tiba. Gunakan shadow root deklaratif, lalu jelaskan progressive enhancement untuk browser yang tidak mem-parsing atribut tersebut dan untuk custom element yang melakukan upgrade setelah HTML tersedia.

Keahlian utamanya adalah rendering browser, batas komponen, dan kebenaran hidrasi, sehingga ini termasuk dalam frontend.

Hal yang dinilai oleh pewawancara

Pertama, apakah Anda tahu bahwa template yang membawa shadowrootmode="open" atau "closed" diubah oleh parser HTML menjadi shadow root jika didukung?

Kedua, dapatkah Anda menjelaskan bahwa hanya shadow root deklaratif pertama untuk sebuah host yang dilampirkan; yang berikutnya tetap sebagai template dan memerlukan strategi fallback yang disengaja?

Ketiga, dapatkah Anda mempertahankan slot, gaya, aksesibilitas, dan perilaku formulir di seluruh HTML server dan upgrade klien?

Keempat, dapatkah Anda membedakan inspeksi open dari enkapsulasi closed? Mode closed menyembunyikan referensi shadowRoot; ini bukan batas keamanan.

Kelima, dapatkah Anda mencegah rendering ganda, listener duplikat, dan event yang hilang selama hidrasi atau streaming?

Pertanyaan untuk diklarifikasi terlebih dahulu

Browser dan mode respons server-rendered mana yang didukung?
Apakah host segera menjadi custom element, atau dapat di-upgrade nanti?
Anak mana yang di-slot, dan apakah konsumen harus menatanya dengan ::slotted?
Apakah mode open diperlukan untuk pengujian dan integrasi, atau apakah mode closed merupakan batasan produk?
Apakah halaman melakukan streaming komponen bersarang atau mengirimkan root lengkap dalam satu respons?
Apa fallback-nya jika parsing deklaratif tidak tersedia?

Kerangka jawaban 30 detik

“Saya akan me-render komponen di server dengan shadow root deklaratif dan fallback light-DOM semantik, lalu membiarkan upgrade custom element melampirkan perilaku tanpa membuat ulang root yang sudah di-parsing. Saya akan menggunakan slot untuk konten publik, menjaga gaya tetap di dalam root, memilih mode open atau closed sebagai keputusan integrasi alih-alih kontrol keamanan, dan melakukan feature-detect shadowRootMode. Hidrasi bersifat idempoten, event didelegasikan atau diikat sekali, dan pengujian mencakup browser yang tidak didukung, urutan streaming, slot, aksesibilitas, dan waktu upgrade.”

Jawaban langkah demi langkah

Langkah 1: Render root semantik

Server memancarkan host dengan template deklaratif. Jaga agar teks dan kontrol tetap bermakna sehingga respons tetap berguna sebelum JavaScript. Gunakan open saat perkakas atau integrasi memerlukan inspeksi; gunakan closed hanya jika kontrak komponen sengaja menyembunyikan referensi tersebut.

html

<product-card>
  <template shadowrootmode="open">
    <style>:host { display: block }</style>
    <article><slot name="title"></slot><button>Buy</button></article>
  </template>
  <span slot="title">Keyboard</span>
</product-card>

Penetapan slot adalah bagian dari kontrak publik. Jangan menduplikasi judul di dalam shadow tree dan konten fallback kecuali Anda juga mengontrol semantik aksesibilitas.

Langkah 2: Tentukan kontrak upgrade

Ketika kelas custom element didefinisikan, siklus hidupnya harus mendeteksi shadow root yang ada daripada memanggil attachShadow lagi. Inisialisasi status sekali, ikat listener sekali, dan biarkan node yang disediakan server tetap di tempatnya. Jika browser tidak membuat root, elemen dapat membuatnya dari template atau me-render fallback light-DOM yang kompatibel.

Langkah 3: Deteksi fitur dan buat fallback

Periksa dukungan dengan parser probe kecil atau properti template yang relevan sebelum mengandalkan perilaku deklaratif. Browser yang tidak didukung harus tetap menerima konten light-DOM semantik; upgrade sisi klien dapat melampirkan shadow root nanti, tetapi tidak boleh menyembunyikan konten selama transisi.

Langkah 4: Pertahankan slot dan gaya

Slot memproyeksikan anak light-DOM ke dalam shadow tree. Dokumentasikan named slot, perilaku slot default, dan batasan penataan gaya seperti ::slotted. Pertahankan gaya komponen di dalam root, dan ekspos custom properties atau parts yang disengaja daripada bergantung pada selektor yang tidak dapat melewati batas.

Langkah 5: Tangani streaming dan penyusunan bersarang

Streaming dapat mengirimkan host sebelum anak yang di-slot bersarang atau sebelum definisi custom-element. Perlakukan urutan parsing sebagai status yang diharapkan: slot harus diperbarui saat anak tiba, dan upgrade harus aman sebelum atau setelah streaming selesai. Hindari mengganti host dengan hierarki kedua.

Langkah 6: Hidrasi perilaku tanpa pekerjaan duplikat

Lampirkan event handler sekali, sebaiknya melalui delegasi tingkat root untuk kartu yang berulang. Tandai inisialisasi dalam field privat atau weak map, bukan atribut publik yang dapat ditimpa oleh konsumen. Pertahankan status formulir dan fokus saat perilaku dilampirkan.

Langkah 7: Uji batas browser dan aksesibilitas

Uji parser yang didukung dan tidak didukung, mode open dan closed, satu versus beberapa root deklaratif, slot yang tiba terlambat, upgrade custom-element sebelum dan sesudah parsing, fokus keyboard, label, pengiriman formulir, dan hidrasi setelah gangguan jaringan. Pastikan terdapat satu hierarki kontrol interaktif dan tidak ada event duplikat.

Jawaban model

“Saya akan melakukan streaming host semantik ditambah satu shadow root deklaratif, menggunakan named slot untuk konten publik, dan menjaga gaya tetap di dalam root. Upgrade custom-element pertama-tama memeriksa apakah root sudah ada, sehingga hidrasi menyempurnakan markup server alih-alih menggantinya. Mode open mendukung inspeksi; mode closed hanya menyembunyikan referensi dan bukan batas keamanan.

Saya akan mendeteksi dukungan parser dan mempertahankan konten fallback light-DOM. Streaming dan upgrade yang terlambat adalah status normal, sehingga proyeksi slot dan inisialisasi harus idempoten. Pengujian mencakup browser yang tidak didukung, root bersarang, slot terlambat, fokus, formulir, aksesibilitas, dan pencegahan event duplikat.”

Kesalahan umum

Memanggil attachShadow pada setiap upgrade → root atau status yang ada hilang → gunakan kembali root yang telah di-parsing.
Menganggap mode closed sebagai keamanan → pemanggil masih dapat berinteraksi melalui perilaku yang diekspos → dokumentasikan ini hanya sebagai enkapsulasi.
Menduplikasi konten fallback dan shadow → pembaca layar mungkin membacanya dua kali → tentukan satu sumber yang dapat diakses.
Mengasumsikan slot tiba sebelum parsing selesai → anak yang di-stream menghilang dari mental model → uji proyeksi yang terlambat.
Menata konten yang di-slot dengan selektor internal → aturan tidak melintasi batas → gunakan ::slotted, parts, atau custom properties.
Mengikat listener pada setiap rendering → klik terpicu berkali-kali → jadikan hidrasi bersifat idempoten.
Menghilangkan fallback light-DOM → browser yang tidak didukung menampilkan kartu kosong → pertahankan markup server semantik.

Pertanyaan lanjutan

Lanjutan 1: Apakah shadow root deklaratif selalu dilampirkan?

Tidak. Ini tergantung pada dukungan parser dan mode yang valid. Browser yang tidak didukung membiarkan template sebagai konten biasa, sehingga diperlukan fallback atau upgrade klien.

Lanjutan 2: Mengapa hanya satu root per host?

Parser melampirkan shadow root deklaratif pertama untuk host tersebut; template berikutnya tetap tersedia untuk penanganan yang disengaja daripada membuat root yang saling bersaing.

Lanjutan 3: Kapan memilih mode open?

Pilih mode open saat pengujian, integrasi, atau ekstensi terkontrol memerlukan referensi root. Mode ini tidak memberikan atau menghapus hak istimewa keamanan.

Lanjutan 4: Bagaimana cara kerja slot selama streaming?

Host dapat ada sebelum anak yang di-slot; setelah anak tiba, penetapan slot akan diperbarui. Pengujian harus mencakup kedua urutan kedatangan tersebut.

Lanjutan 5: Bagaimana cara menghindari ketidakcocokan hidrasi?

Jaga agar kontrak server dan klien tetap stabil, gunakan kembali node yang ada, dan buat inisialisasi menjadi idempoten alih-alih me-render hierarki kedua.

Lanjutan 6: Bagaimana cara menguji closed root?

Uji perilaku yang terlihat oleh pengguna, fokus, event, dan aksesibilitas melalui kontrak publik; jangan mengandalkan pembacaan shadowRoot secara langsung.