Penerangan produk mungkin sama bagi semua pelawat, tetapi alamat penghantaran yang dipaparkan kepada pengguna yang sudah log masuk boleh berbeza. Adakah penerangan produk juga perlu menunggu jika pencarian alamat lambat? Artikel ini menggunakan halaman jualan buku rekaan untuk meneliti proses membuat keputusan tentang pemisahan kandungan bersama daripada bahagian khusus pengguna. Ciri yang diterangkan ialah pulau pelayan Astro, yang berbeza peranan daripada pulau klien yang mengaktifkan butang dalam pelayar.
1. Bezakan dokumen awal daripada bahagian yang tiba kemudian
Dokumentasi rasmi pulau pelayan Astro menerangkan cara menangguhkan pemaparan pelayan bagi komponen tertentu dan menerima hasilnya melalui permintaan berasingan. HTML awal mengandungi kandungan utama dan paparan semasa menunggu; apabila respons berasingan tiba, bahagian itu diganti. Ini memerlukan penyesuai untuk mengendalikan permintaan pada pelayan.
Dalam halaman jualan buku, biarkan tajuk, pengarang dan pengenalan dalam dokumen bersama, dan pilih hanya ringkasan alamat sebagai calon. Pelawat masih boleh membaca tentang buku ketika menunggu alamat. Sebaliknya, jika jumlah pesanan diperlukan untuk memahami butang pembayaran, hubungan antara harga dengan tindakan pembayaran juga perlu direka bersama. Memotong unsur yang kelihatan kepada kotak kecil sahaja tidak menyelesaikan pemisahan fungsi.
Kejayaan reka bentuk ini ditentukan oleh apa yang dipaparkan dahulu. Jika kandungan hampir kosong sementara kebanyakannya ditangguhkan, pelawat menunggu beberapa penunjuk pemuatan. Senaraikan dahulu soalan yang perlu dijawab pada paparan pertama dan maklumat yang boleh tiba lewat. Pulau pelayan ialah alat mengalihkan tempat menunggu, bukan fungsi yang secara automatik mempercepat pertanyaan pangkalan data itu sendiri.
2. Reka fallback sebagai sebahagian paparan yang lengkap
Berikut ialah contoh kecil bentuk penggunaannya. Komponen UserDelivery dan penyesuai dianggap sudah dilaksanakan secara berasingan.
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">Maklumat alamat penghantaran sedang diperiksa.</p>
</UserDelivery>fallback bukan hiasan yang muncul seketika lalu hilang, tetapi kandungan awal yang benar-benar dibaca pelawat. Sediakan ruang yang hampir sama dengan saiz akhir kad alamat dan terangkan apa yang sedang ditunggu. Memaparkan “Penghantaran tersedia” sebelum maklumat diperoleh boleh bercanggah dengan makna respons sebenar. Keadaan belum diketahui dan hasil yang disahkan juga perlu dibezakan secara visual.
Sebagai contoh, pelawat yang belum log masuk mungkin memerlukan pesanan “Log masuk untuk melihat alamat penghantaran yang disimpan.” Rangkaian lambat dan belum log masuk ialah keadaan berbeza. Menentukan teks serta laluan navigasi masing-masing mengurangkan risiko ayat sementara untuk kemudahan pembangunan tertinggal pada paparan sebenar.
3. Kekalkan sempadan data yang kecil
Apabila memanggil komponen, hantarkan hanya nilai yang diperlukan untuk paparan dan pertanyaan. Jika seluruh sejarah pesanan dihantar tetapi hanya satu nama dipaparkan, ada peluang mengurangkan kebergantungan data terlebih dahulu. Sesetengah nilai boleh berada dalam kandungan awam, manakala nilai lain hanya patut dicari selepas pengesahan pengguna. Semak laluan penghantaran nilai dan skop output pada skrin dalam senarai yang sama.
Permintaan pulau pelayan berada dalam konteks pelaksanaan yang berasingan. Jika logik memerlukan alamat halaman semasa, pertimbangkan untuk menghantar laluan yang diperlukan secara jelas daripada halaman asal. Menganggap URL permintaan di dalam pulau sebagai URL halaman produk asal boleh menghasilkan cadangan khusus halaman atau pautan kembali yang salah. Semasa pelaksanaan, lebih selamat memeriksa alamat permintaan sebenar melalui alat pembangun.
Pertimbangkan kes rekaan yang mengendalikan nombor buku dan maklumat pengenalan pengguna. Bahagikan peranan: nombor buku digunakan untuk mencari data cadangan bersama, manakala maklumat pengguna dikendalikan pada pelayan menurut keadaan pengesahan. Walaupun format penghantaran disulitkan, ia tidak menggantikan semakan kebenaran pada pelayan. Dokumentasikan secara berasingan tempat input diterima dan tempat kebenaran akses akhir diputuskan.
4. Tentukan cache mengikut penerima paparan
Sukar menggunakan dasar cache yang sama untuk pengenalan buku bersama dan alamat peribadi. Panduan cache HTTP MDN menerangkan perbezaan cache bersama dan cache peribadi. Nilai dahulu kepada siapa respons boleh dipaparkan, bukan sekadar sama ada datanya sama.
Buka halaman yang sama dengan dua akaun ujian dan pastikan alamat akaun pertama tidak muncul pada akaun kedua. Semak juga selepas log keluar apabila kembali ke halaman atau memuat semula. Ujian ini menilai hasil gabungan pelayan cache, pelayar dan pengendalian pengesahan aplikasi. Membaca fail komponen sahaja tidak cukup untuk menyimpulkan bahawa ia selamat.
Bahagian yang boleh dikongsi, seperti cadangan buku umum, juga memerlukan laluan kemas kini apabila kandungan berubah. Tentukan sama ada cadangan lama boleh diterima seketika atau mesti diganti serta-merta selepas suntingan pentadbir. Daripada satu ayat “hidupkan cache”, tuliskan sasaran, lokasi simpanan, tahap kelapukan yang dibenarkan dan syarat pembatalan supaya pembangun lain mudah menyemak reka bentuk.
5. Uji sambungan lambat dan kegagalan terlebih dahulu
Jangan menilai halaman hanya daripada sekali membukanya pada sambungan normal. Lambatkan permintaan alamat, gagalkannya dan tukar keadaan log masuk, kemudian semak setiap paparan. Periksa sama ada kandungan utama masih boleh dibaca, kawasan pemuatan terus menolak butang seterusnya, dan tindakan yang bergantung pada maklumat gagal masih boleh dilakukan.
| Situasi ujian | Keadaan yang perlu difahami pelawat |
|---|---|
| Pencarian alamat lambat | Apa yang ditunggu, dan bolehkah kandungan lain dibaca? |
| Belum disahkan | Adakah arahan log masuk dan penerangan bersama kelihatan? |
| Pencarian gagal | Bolehkah laluan pemulihan ditemui, bukannya paparan kosong? |
| Akaun ditukar | Adakah maklumat pengguna terdahulu tidak tertinggal? |
Jika beberapa pulau menunggu hasil satu sama lain, cara pemisahannya perlu disemak semula. Struktur yang menerima alamat, kemudian mencari kos penghantaran, kemudian melukis arahan pembayaran boleh menghasilkan permintaan menunggu berturutan. Dalam keadaan ini, lebih baik mungkin menggabungkan maklumat berkaitan dalam satu kerja pelayan, atau mencarinya apabila pengguna meminta. Banyaknya bahagian yang dipisahkan sahaja tidak menjadikan struktur itu baik.
6. Bandingkan manfaat sebelum dan selepas dalam keadaan sama
Dalam rekod perbandingan, asingkan masa kandungan pertama kelihatan, alamat selesai dipaparkan, tindakan tersedia dan keadaan ralat. Walaupun dokumen awal cepat muncul, pengalaman pelawat boleh berubah ke arah lain jika kad alamat bergerak jauh atau pembayaran bermula lebih lambat. Jangan catat satu purata sahaja; rekodkan juga apa yang ditunggu dalam kes lambat.
Soalan untuk memilih calon pulau pelayan lebih berguna apabila khusus. “Bolehkah pengenalan buku dibaca dahulu walaupun maklumat ini lewat?” lebih membantu keputusan pelaksanaan berbanding “Adakah laman ini statik?” Semak persekitaran penggunaan bersama panduan pemaparan atas permintaan Astro, kemudian sahkan satu bahagian kecil khusus pengguna sehingga keadaan kegagalan sebenar.