pustaka kelas ASP.NET Core Razor (RCL) dengan penyajian sisi server statis (SSR statis)

Artikel ini menyediakan panduan untuk penulis pustaka komponen yang mempertimbangkan dukungan untuk penyajian sisi server statis (SSR statis).

Blazor mendorong pengembangan ekosistem pustaka komponen sumber terbuka dan komersial, yang secara resmi disebut Razor pustaka kelas (RCL). Pengembang mungkin juga membuat komponen yang dapat digunakan kembali untuk berbagi komponen secara privat di seluruh aplikasi dalam perusahaan mereka sendiri. Idealnya, komponen dikembangkan untuk kompatibilitas dengan model hosting sebanyak mungkin dan mode penyajian. SSR statis memperkenalkan pembatasan tambahan yang dapat lebih menantang untuk didukung daripada mode penyajian interaktif.

Memahami kemampuan dan pembatasan SSR statis

SSR statis adalah mode di mana komponen berjalan ketika server menangani permintaan HTTP masuk. Blazor merender komponen sebagai HTML, yang disertakan dalam respons. Setelah respons dikirim, komponen sisi server dan status perender dibuang, jadi yang tersisa adalah HTML di browser.

Manfaat dari mode ini lebih murah, hosting yang lebih dapat diskalakan, karena tidak ada sumber daya server yang sedang berlangsung yang diperlukan untuk menahan status komponen, tidak ada koneksi yang sedang berlangsung yang harus dipertahankan antara browser dan server, dan tidak ada payload WebAssembly yang diperlukan di browser.

Secara default, semua komponen yang ada masih dapat digunakan dengan SSR statis. Namun, biaya mode ini adalah bahwa penanganan aktivitas, seperti @onclick†, tidak dapat dijalankan karena alasan berikut:

• Tidak ada kode .NET di browser untuk menjalankannya.
• Server telah segera membuang komponen dan status perender apa pun yang akan diperlukan untuk menjalankan penanganan aktivitas atau untuk merender instans komponen yang sama.

†Kecualian khusus untuk @onsubmit penanganan aktivitas untuk formulir, yang selalu berfungsi, terlepas dari mode render.

Ini setara dengan bagaimana komponen berperilaku selama pra-penyajian, sebelum Blazor sirkuit atau Blazor WebAssembly runtime dimulai.

Untuk komponen yang satu-satunya perannya adalah menghasilkan konten DOM baca-saja, perilaku ini untuk SSR statis benar-benar cukup. Namun, penulis pustaka harus mempertimbangkan pendekatan apa yang harus diambil ketika menyertakan komponen interaktif di pustaka mereka.

Opsi untuk penulis komponen

Ada tiga pendekatan utama:

• Jangan gunakan perilaku interaktif (Dasar)

  Untuk komponen yang satu-satunya perannya adalah menghasilkan konten DOM baca-saja, pengembang tidak diharuskan untuk mengambil tindakan khusus apa pun. Komponen-komponen ini secara alami bekerja dengan mode render apa pun.

  Contoh:

  • Komponen "kartu pengguna" yang memuat data yang sesuai dengan seseorang dan merendernya dalam antarmuka pengguna bergaya dengan foto, jabatan kerja, dan detail lainnya.
  • Komponen "video" yang bertindak sebagai pembungkus di sekitar elemen HTML <video> , membuatnya lebih nyaman digunakan dalam komponen Razor .

• Memerlukan penyajian interaktif (Dasar)

  Anda dapat memilih untuk mengharuskan komponen Anda hanya digunakan dengan penyajian interaktif. Ini membatasi penerapan komponen Anda, tetapi berarti Anda dapat dengan bebas mengandalkan penanganan peristiwa arbitrer. Bahkan kemudian, Anda masih harus menghindari mendeklarasikan tertentu @rendermode dan mengizinkan penulis aplikasi yang menggunakan pustaka Anda untuk memilihnya.

  Contoh:

  • Komponen pengeditan video di mana pengguna dapat memata-matai dan memesan ulang segmen video. Bahkan jika ada cara untuk mewakili operasi edit ini dengan tombol HTML biasa dan posting formulir, pengalaman pengguna akan tidak dapat diterima tanpa interaktivitas sejati.
  • Editor dokumen kolaboratif yang harus menampilkan aktivitas pengguna lain secara real time.

• Gunakan perilaku interaktif, tetapi desain untuk SSR statis dan peningkatan progresif (Tingkat Lanjut)

  Banyak perilaku interaktif yang dapat diimplementasikan hanya menggunakan kemampuan HTML. Dengan pemahaman yang baik tentang HTML dan CSS, Anda sering dapat menghasilkan garis besar fungsionalitas yang berguna yang berfungsi dengan SSR statis. Anda masih dapat mendeklarasikan penanganan aktivitas yang menerapkan perilaku opsional yang lebih canggih, yang hanya berfungsi dalam mode render interaktif.

  Contoh:

  • Komponen kisi. Di bawah SSR statis, komponen hanya dapat mendukung menampilkan data dan menavigasi antar halaman (diimplementasikan dengan <a> tautan). Saat digunakan dengan penyajian interaktif, komponen dapat menambahkan pengurutan dan pemfilteran langsung.
  • Komponen tabset. Selama navigasi antar tab dicapai menggunakan <a> tautan dan status hanya disimpan dalam parameter kueri URL, komponen dapat berfungsi tanpa @onclick.
  • Komponen pengunggah file tingkat lanjut. Di bawah SSR statis, komponen mungkin berperilaku sebagai asli <input type=file>. Saat digunakan dengan penyajian interaktif, komponen juga dapat menampilkan kemajuan pengunggahan.
  • Sebuah saham ticker. Di bawah SSR statis, komponen dapat menampilkan kutipan stok pada saat HTML dirender. Ketika digunakan dengan penyajian interaktif, komponen kemudian dapat memperbarui harga saham secara real time.

Untuk salah satu strategi ini, ada juga opsi untuk menerapkan fitur interaktif dengan JavaScript.

Untuk memilih di antara pendekatan ini, penulis komponen yang dapat Razor digunakan kembali harus membuat tradeoff biaya/manfaat. Komponen Anda lebih berguna dan memiliki basis pengguna potensial yang lebih luas jika mendukung semua mode render, termasuk SSR statis. Namun, dibutuhkan lebih banyak pekerjaan untuk merancang dan mengimplementasikan komponen yang mendukung dan mengambil keuntungan terbaik dari setiap mode render.

Kapan menggunakan direktif @rendermode

Dalam kebanyakan kasus, penulis komponen yang dapat digunakan kembali tidak boleh menentukan mode render, bahkan ketika interaktivitas diperlukan. Ini karena pembuat komponen tidak tahu apakah aplikasi mengaktifkan dukungan untuk InteractiveServer, , InteractiveWebAssemblyatau keduanya dengan InteractiveAuto. Dengan tidak menentukan @rendermode, pembuat komponen meninggalkan pilihan kepada pengembang aplikasi.

Bahkan jika penulis komponen berpikir bahwa interaktivitas diperlukan, mungkin masih ada kasus di mana penulis aplikasi menganggapnya cukup untuk menggunakan SSR statis saja. Misalnya, komponen peta dengan interaktivitas seret dan perbesar tampilan mungkin tampak memerlukan interaktivitas. Namun, beberapa skenario hanya dapat memanggil untuk merender gambar peta statis dan menghindari fitur seret/zoom.

Satu-satunya alasan mengapa penulis komponen yang dapat digunakan kembali harus menggunakan @rendermode arahan pada komponen mereka adalah jika implementasi pada dasarnya digabungkan ke satu mode render tertentu dan pasti akan menyebabkan kesalahan jika digunakan dalam mode yang berbeda. Pertimbangkan komponen dengan tujuan inti berinteraksi langsung dengan OS host menggunakan API khusus Windows atau Linux. Mungkin tidak mungkin untuk menggunakan komponen seperti itu di WebAssembly. Jika demikian, wajar untuk mendeklarasikan @rendermode InteractiveServer komponen.

Penyajian streaming

Komponen yang dapat Razor digunakan kembali bebas untuk dinyatakan @attribute [StreamRendering] untuk penyajian streaming ([StreamRendering] API atribut). Ini menghasilkan pembaruan UI inkremental selama SSR statis. Karena pola pemuatan data yang sama menghasilkan pembaruan UI bertambah bertahap selama penyajian interaktif, terlepas dari [StreamRendering] keberadaan atribut, komponen dapat berperilaku dengan benar dalam semua kasus. Bahkan dalam kasus di mana SSR statis streaming ditekan di server, komponen masih merender status akhir yang benar.

Menggunakan tautan di seluruh mode render

Komponen yang dapat Razor digunakan kembali dapat menggunakan tautan dan navigasi yang disempurnakan. Tag HTML <a> harus menghasilkan perilaku yang setara dengan atau tanpa komponen interaktif Router dan apakah navigasi yang ditingkatkan diaktifkan/dinonaktifkan pada tingkat leluhur di DOM atau tidak.

Menggunakan formulir di seluruh mode render

Komponen yang dapat Razor digunakan kembali dapat mencakup formulir (baik <form> atau <EditForm>), karena dapat diimplementasikan untuk bekerja secara setara di mode render statis dan interaktif.

Pertimbangkan contoh berikut:

<EditForm Enhance FormName="NewProduct" Model="Model" OnValidSubmit="SaveProduct">
    <DataAnnotationsValidator />
    <ValidationSummary />

    <p>Name: <InputText @bind-Value="Item.Name" /></p>

    <button type="submit">Submit</button>
</EditForm>

@code {
    [SupplyParameterFromForm]
    public Product? Model { get; set; }

    protected override void OnInitialized() => Model ??= new();

    private async Task Save()
    {
        ...
    }
}

EnhanceAPI , FormName, dan SupplyParameterFromFormAttribute hanya digunakan selama SSR statis dan diabaikan selama penyajian interaktif. Formulir berfungsi dengan benar selama SSR interaktif dan statis.

Hindari API yang khusus untuk SSR statis

Untuk membuat komponen yang dapat digunakan kembali yang berfungsi di semua mode render, jangan mengandalkan HttpContext karena hanya tersedia selama SSR statis. HttpContext API tidak masuk akal untuk digunakan selama penyajian interaktif karena tidak ada permintaan HTTP aktif dalam penerbangan pada saat itu. Tidak ada artinya untuk berpikir tentang mengatur kode status atau menulis ke respons.

Komponen yang dapat digunakan kembali gratis untuk menerima HttpContext jika tersedia, sebagai berikut:

[CascadingParameter]
public HttpContext? Context { get; set; }

Nilainya adalah null selama penyajian interaktif dan hanya diatur selama SSR statis.

Dalam banyak kasus, ada alternatif yang lebih baik daripada menggunakan HttpContext. Jika Anda perlu mengetahui URL saat ini atau untuk melakukan pengalihan, API yang berfungsi NavigationManager dengan semua mode render. Jika Anda perlu mengetahui status autentikasi pengguna, gunakan Blazorlayanan menggunakan AuthenticationStateProviderHttpContext.User.