Mô tả sản phẩm giống nhau cho mọi khách, nhưng địa chỉ giao hàng hiển thị cho người đăng nhập có thể khác. Truy vấn địa chỉ chậm thì có nên để mô tả sản phẩm cũng chờ? Bài này dùng trang bán sách giả định để xem quá trình quyết định tách nội dung chung và vùng riêng người dùng. Tính năng là server island Astro, khác vai trò client island làm nút hoạt động trong trình duyệt.
1. Tách tài liệu đầu và vùng tới sau
Tài liệu server island chính thức Astro giải thích trì hoãn kết xuất máy chủ của thành phần cụ thể và nhận kết quả qua yêu cầu riêng. HTML đầu chứa nội dung chính cùng hiển thị lúc chờ; khi phản hồi riêng đến thì thay vùng đó. Cần adapter xử lý yêu cầu trên máy chủ để thực hiện.
Trong trang sách, giữ tên, tác giả, giới thiệu ở tài liệu chung và chỉ chọn tóm tắt địa chỉ làm ứng viên. Khách có thể đọc sách là gì trong lúc chờ địa chỉ. Ngược lại, nếu phải biết tổng đơn để hiểu nút thanh toán, cần thiết kế cả quan hệ giá với hành động thanh toán. Chia thứ nhìn thấy thành hộp nhỏ không tự hoàn tất tách chức năng.
Thành bại thiết kế do thứ hiển thị trước quyết định. Để thân gần trống và trì hoãn đa số khiến khách chờ nhiều dấu tải. Liệt kê trước câu hỏi phải trả lời màn đầu và thông tin có thể tới muộn. Server island đổi vị trí chờ, không tự làm truy vấn cơ sở dữ liệu nhanh.
2. Thiết kế fallback như phần của màn hình hoàn chỉnh
Sau là ví dụ nhỏ minh họa cách dùng. Giả định thành phần UserDelivery và adapter đã triển khai riêng.
---
import UserDelivery from '../components/UserDelivery.astro';
---
<UserDelivery server:defer>
<p slot="fallback">Đang kiểm tra địa chỉ giao hàng.</p>
</UserDelivery>fallback không là trang trí thoáng hiện rồi biến, mà là nội dung đầu khách thực đọc. Dành chỗ gần cỡ cuối thẻ địa chỉ, giải thích chờ gì. Chưa có dữ liệu đã ghi “Có thể giao” có thể mâu thuẫn nghĩa phản hồi thật. Cũng phải phân biệt trực quan trạng thái chưa biết với kết quả xác nhận.
Ví dụ khách chưa đăng nhập có thể cần “Đăng nhập để xem địa chỉ đã lưu”. Mạng chậm và chưa đăng nhập là hai trạng thái khác. Định riêng câu chữ, đường đi sẽ giảm việc câu tạm cho tiện phát triển bị để lại màn vận hành.
3. Giữ ranh giới dữ liệu nhỏ
Gọi thành phần chỉ truyền giá trị cần hiển thị, truy vấn. Nếu truyền cả lịch sử đơn chỉ in một tên, có thể giảm phụ thuộc dữ liệu trước. Một số giá trị được công khai, số khác chỉ truy vấn sau xác thực. Kiểm tra đường truyền giá trị và phạm vi in lên màn trong cùng danh sách.
Yêu cầu server island ở ngữ cảnh thực thi riêng. Logic cần URL trang hiện tại thì xem xét truyền rõ đường cần từ trang gốc. Mặc định URL yêu cầu trong island là trang sản phẩm gốc có thể tạo gợi ý hoặc link quay về sai. Khi triển khai nên kiểm địa chỉ yêu cầu thật bằng công cụ nhà phát triển.
Hãy xét tình huống giả định xử lý mã sách và định danh người dùng. Chia vai: mã sách truy vấn gợi ý chung, thông tin người dùng xử lý máy chủ theo xác thực. Dù dùng dạng truyền mã hóa cũng không thay kiểm quyền máy chủ. Tài liệu hóa riêng chỗ nhận đầu vào và chỗ quyết định cho truy cập cuối.
4. Chọn cache theo đối tượng màn hình
Khó áp cùng chính sách cache cho giới thiệu sách chung và địa chỉ riêng. Hướng dẫn HTTP cache MDN phân biệt cache dùng chung, riêng. Đánh giá phản hồi được cho ai thấy trước, không chỉ dữ liệu có giống.
Mở cùng trang bằng hai tài khoản thử, xác nhận địa chỉ tài khoản đầu không hiện ở tài khoản sau. Xem cả sau đăng xuất, quay lại hoặc tải lại. Thử nghiệm nhắm kết quả kết hợp máy chủ cache, trình duyệt, xử lý xác thực ứng dụng. Không thể chỉ đọc file thành phần rồi kết luận an toàn.
Ngay phần chia sẻ được như gợi ý sách chung cũng cần đường cập nhật khi đổi nội dung. Quyết định có cho gợi ý cũ tạm hay thay ngay khi quản trị sửa. Hơn một câu “bật cache”, ghi đối tượng, nơi lưu, độ cũ cho phép, điều kiện vô hiệu giúp người khác kiểm thiết kế.
5. Thử kết nối chậm, thất bại trước
Không đánh giá trang từ một lần mở mạng bình thường. Làm chậm, làm lỗi yêu cầu địa chỉ, đổi đăng nhập rồi kiểm từng màn. Xem thân chính có đọc được, vùng tải có đẩy nút tiếp mãi, thao tác phụ thuộc dữ liệu lỗi có còn thực hiện được.
| Tình huống thử | Trạng thái khách cần hiểu |
|---|---|
| Truy vấn địa chỉ chậm | Đang chờ gì, có đọc phần khác được không? |
| Chưa xác thực | Có hướng dẫn đăng nhập và giải thích chung không? |
| Truy vấn lỗi | Có tìm được đường phục hồi thay màn trống không? |
| Đổi tài khoản | Có còn thông tin người trước không? |
Nhiều island chờ kết quả nhau thì phải xem lại cách tách. Nhận địa chỉ rồi hỏi phí rồi vẽ thanh toán có thể chuỗi yêu cầu chờ. Khi đó có thể tốt hơn gộp thông tin liên quan thành một tác vụ máy chủ hoặc truy vấn lúc người dùng yêu cầu. Nhiều phần tách không tự thành cấu trúc tốt.
6. So lợi ích trước, sau trong cùng điều kiện
Ghi so sánh riêng thời điểm thấy thân đầu, địa chỉ xong, thao tác được, trạng thái lỗi. Tài liệu đầu nhanh nhưng thẻ địa chỉ dịch lớn hay bắt đầu trả tiền chậm thì trải nghiệm đổi hướng khác. Không ghi mỗi trung bình, cũng lưu ca chậm đã chờ gì.
Câu hỏi chọn server island càng cụ thể càng tốt. “Thông tin này trễ nhưng đọc giới thiệu trước được không?” giúp quyết định hơn “Trang này tĩnh không?”. Xem môi trường triển khai cùng hướng dẫn kết xuất theo yêu cầu Astro, rồi xác minh từ một vùng nhỏ theo người đến cả lỗi thật.