ASP.NET alapvető Razor osztálykódtárak (RCLs) statikus kiszolgálóoldali rendereléssel (statikus SSR)

Megjegyzés:

Ez nem a cikk legújabb verziója. Az aktuális kiadásról a cikk .NET 10-es verziójában olvashat.

Ez a cikk útmutatást nyújt az összetevőtár-szerzők számára, figyelembe véve a statikus kiszolgálóoldali renderelés (statikus SSR) támogatását.

Blazor ösztönzi a nyílt forráskódú és kereskedelmi összetevőkből álló kódtárak, formálisan Razor osztálykódtárak (RCL-ek) ökoszisztémájának fejlesztését. A fejlesztők újrahasználható összetevőket is létrehozhatnak az összetevők privát megosztásához a saját vállalataik alkalmazásaiban. Ideális esetben az összetevők a lehető legtöbb üzemeltetési modellel és megjelenítési móddal való kompatibilitás érdekében lettek kifejlesztve. A statikus SSR további korlátozásokat vezet be, amelyek támogatása nagyobb kihívást jelenthet, mint az interaktív megjelenítési módok.

A statikus SSR képességeinek és korlátainak megismerése

A statikus SSR egy olyan mód, amelyben az összetevők akkor futnak, amikor a kiszolgáló egy bejövő HTTP-kérést kezel. Blazor HTML-ként jeleníti meg az összetevőt, amelyet a válasz tartalmaz. A válasz elküldése után a kiszolgálóoldali összetevő és a renderelő állapota el lesz vetve, így csak a HTML marad a böngészőben.

Ennek a módnak az előnye az olcsóbb, méretezhetőbb üzemeltetés, mivel nincs szükség folyamatos kiszolgálói erőforrásokra az összetevő állapotának megőrzéséhez, a böngésző és a kiszolgáló közötti folyamatos kapcsolatot nem kell fenntartani, és a böngészőben nincs szükség a WebAssembly hasznos adataira.

Az összes meglévő összetevő továbbra is használható statikus SSR-vel. Ennek a módnak a költsége azonban az, hogy az eseménykezelők( például @onclick†) nem futtathatók a következő okok miatt:

• A böngészőben nincs .NET-kód a futtatáshoz.
• A kiszolgáló azonnal elvetett minden olyan összetevőt és renderelőállapotot, amely az eseménykezelők végrehajtásához vagy ugyanazon összetevőpéldányok újrarendezéséhez szükséges.

†Az űrlapok eseménykezelő esetében különleges kivétel van, amely a renderelési módtól függetlenül mindig működőképes.

Ez egyenértékű azzal, ahogy az összetevők az előfeldolgozás során viselkednek, mielőtt BlazorSignalR áramköre vagy a .NET WebAssembly futtatókörnyezet elindulna.

Azoknak az összetevőknek, amelyeknek az egyetlen szerepe az írásvédett DOM-tartalom előállítása, ezek a viselkedések a statikus SSR-hez teljes mértékben elegendőek. A kódtárak szerzőinek azonban figyelembe kell venniük, hogy milyen megközelítést kell alkalmazniuk, ha interaktív összetevőket vesznek fel a táraikba.

Összetevők szerzőinek beállításai

Három fő megközelítés létezik:

• Ne használjon interaktív viselkedést (alapszintű)

  Az olyan összetevők esetében, amelyek egyetlen feladata az írásvédett DOM-tartalom előállítása, a fejlesztőnek nem kell speciális műveleteket végrehajtania. Ezek az összetevők természetesen bármilyen renderelési móddal működnek.

  Examples:

  • Egy "felhasználói kártya" összetevő, amely betölti a személynek megfelelő adatokat, és stilizált felhasználói felületen jeleníti meg fényképpel, beosztással és egyéb részletekkel.
  • Egy "videó" összetevő, amely burkolóként működik a HTML-elem <video> körül, így kényelmesebben használható egy Razor összetevőben.

• Interaktív renderelés megkövetelése (alapszintű)

  Beállíthatja, hogy az összetevő csak interaktív rendereléssel legyen használva. Ez korlátozza az összetevő alkalmazhatóságát, de azt jelenti, hogy szabadon támaszkodhat tetszőleges eseménykezelőkre. Még akkor is el kell kerülnie egy adott @rendermode deklarálást, és engedélyeznie kell a tárat használó alkalmazás szerzőjének, hogy válasszon egyet.

  Examples:

  • Videoszerkesztési összetevő, amelyben a felhasználók megszűkíthetik és átrendezhetik a videó szegmenseit. Még ha lenne is mód arra, hogy egyszerű HTML-gombokkal és űrlapbejegyzésekkel ábrázolja ezeket a szerkesztési műveleteket, a felhasználói élmény nem lenne elfogadható valódi interaktivitás nélkül.
  • Együttműködési dokumentumszerkesztő, amely valós időben jeleníti meg más felhasználók tevékenységeit.

• Interaktív viselkedések használata, de statikus szerveroldali renderelés és fokozatos javítás tervezése (Speciális)

  Számos interaktív viselkedés csak HTML-képességekkel valósítható meg. A HTML és a CSS alapos ismeretével gyakran hasznos alapkonfigurációt hozhat létre a statikus SSR-vel működő funkciókhoz. Továbbra is deklarálhatja azokat az eseménykezelőket, amelyek speciálisabb, választható viselkedéseket implementálnak, amelyek csak interaktív renderelési módban működnek.

  Examples:

  • Egy rácsösszetevő. Statikus SSR esetén az összetevő csak az adatok megjelenítését és a lapok közötti navigálást támogatja (hivatkozásokkal <a> implementálva). Interaktív renderelés esetén az összetevő élő rendezést és szűrést adhat hozzá.
  • Tabset összetevő. Mindaddig, amíg a lapok közötti navigálás hivatkozások használatával <a> történik, és az állapot csak URL-lekérdezési paraméterekben van tárolva, az összetevő anélkül is működhet @onclick.
  • Speciális fájlfeltöltési összetevő. Statikus SSR esetén az összetevő natívként <input type=file>viselkedhet. Interaktív renderelés esetén az összetevő a feltöltés előrehaladását is megjelenítheti.
  • Egy tőzsdei jelző. Statikus SSR esetén az összetevő megjelenítheti a tőzsdei árfolyamot a HTML megjelenítésekor. Interaktív renderelés esetén az összetevő ezután valós időben frissítheti a részvényárfolyamot.

Ezen stratégiák bármelyike esetén lehetőség van interaktív funkciók javaScripttel való implementálására is.

E megközelítések közül való választáshoz az újrafelhasználható Razor összetevők szerzőinek költség-haszon kompromisszumot kell hozniuk. Az összetevő hasznosabb, és szélesebb körű felhasználói bázissal rendelkezik, ha minden megjelenítési módot támogat, beleértve a statikus SSR-t is. Azonban több munkát igényel egy olyan összetevő tervezése és implementálása, amely támogatja és a legjobban kihasználja az egyes renderelési módokat.

Mikor érdemes használni az irányelvet?@rendermode

A legtöbb esetben az újrafelhasználható összetevők szerzői nem adhatnak meg renderelési módot, még akkor sem, ha interaktivitásra van szükség. Ennek az az oka, hogy az összetevő szerzője nem tudja, hogy az alkalmazás támogatja-e InteractiveServer, InteractiveWebAssemblyvagy mindkettőt.InteractiveAuto Ha nem határoz meg egy @rendermode elemet, az összetevő szerzője az alkalmazásfejlesztőre bízza a választást.

Még ha az összetevő szerzője azt is gondolja, hogy interaktivitásra van szükség, előfordulhat, hogy az alkalmazás szerzője elegendőnek tartja a statikus SSR használatát. Előfordulhat például, hogy egy húzással és nagyítással rendelkező térképösszetevő interaktivitást igényel. Egyes forgatókönyvek azonban csak statikus térképkép renderelését és a húzási/nagyítási funkciók elkerülését eredményezhetik.

Az egyetlen ok, amiért egy újrafelhasználható összetevő szerzőjének az @rendermode összetevőre vonatkozó irányelvet kell használnia, az az, ha a megvalósítás alapvetően egy adott renderelési módhoz van kapcsolva, és minden bizonnyal hibát okozna, ha más módban használják. Fontolja meg azt az összetevőt, amelynek alapvető célja, hogy közvetlenül a gazdagép operációs rendszerével kommunikáljon Windows vagy Linux-specifikus API-k használatával. Előfordulhat, hogy nem lehet ilyen összetevőt használni a WebAssemblyben. Ha igen, ésszerű deklarálni @rendermode InteractiveServer az összetevőt.

Folyamatos megjelenítés

Az újrahasználható Razor összetevők szabadon deklarálhatók @attribute [StreamRendering]streamelési rendereléshez ([StreamRendering] attribútum API). Ez növekményes felhasználói felületi frissítéseket eredményez a statikus SSR során. Mivel ugyanazok az adatbetöltési minták növekményes felhasználói felületi frissítéseket eredményeznek az interaktív renderelés során, függetlenül az [StreamRendering] attribútum jelenlététől, az összetevő minden esetben megfelelően viselkedhet. Még abban az esetben is, ha a statikus SSR streamelése el van tiltva a kiszolgálón, az összetevő továbbra is a megfelelő végső állapotot jeleníti meg.

Hivatkozások használata renderelési módok között

Az újrahasználható Razor összetevők hivatkozásokat és továbbfejlesztett navigációt használhatnak. A HTML-címkéknek <a> egyenértékű viselkedést kell eredményeznie egy interaktív Router összetevővel vagy anélkül, valamint azt, hogy a továbbfejlesztett navigáció engedélyezve vagy letiltva van-e a DOM elődszintjén.

Űrlapok használata renderelési módok között

Az újrahasználható Razor összetevők tartalmazhatnak űrlapokat (vagy <form><EditForm> ), mivel ezek a statikus és az interaktív megjelenítési módokon is egyenértékű működésre implementálhatók.

Vegye figyelembe a következő példát:

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

    <p><label>Name: <InputText @bind-Value="Model!.Name" /></label></p>

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

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

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

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

A Enhance, FormNameés SupplyParameterFromFormAttribute API-k csak statikus SSR-ben használhatók, és az interaktív renderelés során figyelmen kívül lesznek hagyva. Az űrlap az interaktív és a statikus SSR során is megfelelően működik.

Kerülje a statikus SSR-hez kapcsolódó API-kat

HttpContext csak a statikus SSR-ben érhető el, ezért ne támaszkodjon HttpContext-ra, amikor különböző renderelési módokkal működő összetevőket hoz létre. Az HttpContext API-nak nincs értelme az interaktív renderelés során sem, mert akkoriban nincs aktív HTTP-kérés a repülés során. Értelmetlen átgondolni a HTTP-állapotkód beállítását vagy a HTTP-válaszra való írást.

Az újrahasználható összetevők az alábbiak szerint akkor vehetik át a HttpContext, ha az rendelkezésre áll:

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

Az érték interaktív renderelés során van null beállítva, és csak statikus SSR-ben van beállítva.

Sok esetben jobb alternatíva is létezik, mint a használata HttpContext. Ha ismernie kell az aktuális URL-címet, vagy átirányítást szeretne végrehajtani, az API-k minden megjelenítési NavigationManager móddal működnek. Ha ismernie kell a felhasználó hitelesítési állapotát, használja a BlazorAuthenticationStateProvider szolgáltatást (AuthenticationStateProvider dokumentáció) HttpContext.User használata helyett.