Opis produktu jest jednakowy dla wszystkich, ale adres dostawy zalogowanej osoby może być inny. Czy wolne pobieranie adresu musi wstrzymywać także opis? Na fikcyjnej stronie sprzedaży książek przyjrzymy się decyzji o rozdzieleniu treści wspólnej i obszaru osobistego. Omawiamy Server Islands Astro, których rola różni się od Client Islands uruchamiających przyciski w przeglądarce.
1. Oddzielenie dokumentu początkowego od późniejszych obszarów
Oficjalna dokumentacja Server Islands Astro opisuje opóźnienie renderowania komponentu na serwerze i pobranie wyniku osobnym żądaniem. Początkowy HTML zawiera główną treść i komunikat oczekiwania; późniejsza odpowiedź zastępuje obszar. Potrzebny jest adapter obsługujący żądania na serwerze.
Zostawmy tytuł, autora i opis we wspólnym dokumencie, wybierając tylko podsumowanie adresu. Odwiedzający może czytać o książce podczas oczekiwania. Jeżeli zrozumienie przycisku płatności wymaga znajomości sumy, trzeba też zaprojektować związek ceny z działaniem. Podział widocznych elementów na małe pola nie kończy rozdzielenia funkcji.
Decyduje to, co pokażemy najpierw. Prawie pusta treść główna i opóźnienie większości elementów oznaczają wiele wskaźników ładowania. Najpierw wypisz pytania wymagające odpowiedzi na pierwszym ekranie i informacje, które mogą nadejść później. Server Islands przesuwają miejsce oczekiwania, nie przyspieszają automatycznie samego zapytania do bazy.
2. Fallback jako część gotowego ekranu
Mały przykład pokazuje użycie. Zakłada, że UserDelivery i adapter zaimplementowano osobno.
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">Sprawdzanie adresu dostawy.</p>
</UserDelivery>Fallback nie jest chwilową dekoracją, lecz rzeczywistą początkową treścią. Zarezerwuj przestrzeń zbliżoną do końcowej karty i wyjaśnij oczekiwanie. Przedwczesne „Dostawa dostępna” bez danych może przeczyć odpowiedzi. Stan nieznany i potwierdzony wynik powinny różnić się także wizualnie.
Niezalogowanej osobie może być potrzebne „Zaloguj się, aby zobaczyć zapisany adres dostawy”. Wolna sieć i brak logowania to różne stany. Oddzielne teksty i ścieżki nawigacji ograniczają pozostawianie w produkcji prowizorycznych komunikatów programistycznych.
3. Małe granice danych
Przekazuj tylko wartości potrzebne do wyświetlenia i pobrania. Jeśli cała historia zamówień służy pokazaniu jednego imienia, najpierw można ograniczyć zależności. Niektóre wartości mogą być publiczne, inne pobierane dopiero po uwierzytelnieniu. Sprawdź w jednej liście drogę przekazania i zakres prezentacji.
Żądanie Server Island działa w osobnym kontekście. Jeśli logika potrzebuje adresu bieżącej strony, rozważ jawne przekazanie potrzebnej ścieżki ze strony pierwotnej. Uznanie wewnętrznego URL za adres produktu może tworzyć błędne rekomendacje lub linki powrotne. Sprawdź rzeczywisty adres żądania w narzędziach deweloperskich.
W fikcyjnym przykładzie z numerem książki i identyfikatorem użytkownika pierwszy służy wspólnym rekomendacjom, a serwer obsługuje dane użytkownika według stanu uwierzytelnienia. Nawet szyfrowany format przekazania nie zastępuje kontroli uprawnień na serwerze. Osobno udokumentuj miejsce odbioru wejścia i decyzji o ostatecznym dostępie.
4. Cache według odbiorców ekranu
Wspólny opis i osobisty adres trudno objąć tą samą polityką cache. Przewodnik MDN po cache HTTP rozróżnia cache współdzielony i prywatny. Najpierw oceń, komu można pokazać odpowiedź, nie tylko identyczność danych.
Otwórz stronę dwoma kontami testowymi i sprawdź, czy adres pierwszego nie trafia do drugiego. Przetestuj też cofnięcie i odświeżenie po wylogowaniu. Oceniasz wspólne działanie serwera cache, przeglądarki i uwierzytelniania aplikacji. Sam plik komponentu nie dowodzi bezpieczeństwa.
Także wspólne rekomendacje książek potrzebują ścieżki aktualizacji. Ustal, czy stare mogą pozostać chwilowo, czy zmiana administratora ma działać natychmiast. Zamiast „włącz cache” zapisz przedmiot, miejsce przechowywania, dopuszczalne zestarzenie i warunki unieważnienia, aby inni mogli ocenić projekt.
5. Najpierw wolne połączenia i błędy
Nie oceniaj strony po jednym normalnym otwarciu. Opóźnij żądanie adresu, wywołaj błąd i zmień logowanie, oglądając każdy ekran. Sprawdź czytelność głównej treści, obszary ładowania wypychające kolejne przyciski i działania zależne od brakującej informacji.
| Sytuacja testowa | Stan zrozumiały dla odwiedzającego |
|---|---|
| Wolne pobieranie adresu | Na co czekamy i czy można czytać inne treści |
| Brak uwierzytelnienia | Czy widać logowanie i wspólny opis |
| Błąd pobrania | Czy jest droga odzyskania zamiast pustego ekranu |
| Zmiana konta | Czy nie zostają dane poprzedniej osoby |
Jeśli kilka Islands czeka na siebie, przemyśl podział. Pobranie adresu, potem kosztów dostawy, a następnie informacji płatniczej może tworzyć kolejne oczekiwania. Lepsze może być połączenie danych w jedno zadanie serwera albo pobranie ich na żądanie użytkownika. Więcej oddzielonych części nie oznacza automatycznie lepszej architektury.
6. Porównanie korzyści w tych samych warunkach
Oddzielnie zapisz pierwszą treść, gotowy adres, możliwość obsługi i stany błędów. Szybszy dokument przy mocno przesuwającej się karcie lub późniejszym początku płatności może inaczej zmienić doświadczenie. Oprócz średniej zapisz, na co czekano w wolnych przypadkach.
Konkretne pytania pomagają wybrać kandydata: „Czy można już czytać opis książki, gdy ta informacja się spóźnia?” lepiej wspiera decyzję niż „Czy witryna jest statyczna?”. Sprawdź środowisko z przewodnikiem Astro po renderowaniu na żądanie i zacznij od jednego małego obszaru osobistego, testując także rzeczywiste awarie.