V tomto případě ne, protože on to právě ten "prerender" je a nic dalšího už se neděje. V novém Blazoru spíš budeme řešit otázku jak dlouho se (a kolikrát) HTML posílá na klienta.
19:30 skoda, ze nejde OnInitializeAsync udelat jako async generator a posilat informace o zmene stavu na klienta pres yield return. Tahle StateHasChange metoda je IMO dost neelegantni.
Funguje tak právě celá Blazor komunikace. Souhlasím, že StateHaseChanged s sebou nese režii a měl by se používat jen v odůvodněných případech. Ale vím kam tím míříte a zatím mě nenapadá jak takového chování docílit přirozeně v Blazor SSR. V režimu interaktivity by ale mohlo jít použít gRPC web. Nemám to teď vyzkoušené.
@@MirekHolec První volání StateHasChanged v tom příkladu s kočkama nepotřebujete - není tam změna stavu - komponenta ještě nebyla vykreslena dokud se to na tom prvním awaitu nevrátí
Super video 👍 Blazor začíná být hodně zajímavý
8:50 Nebudou se data nacitat dvakrat kdyz je zapnuty prerender?
V tomto případě ne, protože on to právě ten "prerender" je a nic dalšího už se neděje. V novém Blazoru spíš budeme řešit otázku jak dlouho se (a kolikrát) HTML posílá na klienta.
19:30 skoda, ze nejde OnInitializeAsync udelat jako async generator a posilat informace o zmene stavu na klienta pres yield return. Tahle StateHasChange metoda je IMO dost neelegantni.
Funguje tak právě celá Blazor komunikace. Souhlasím, že StateHaseChanged s sebou nese režii a měl by se používat jen v odůvodněných případech. Ale vím kam tím míříte a zatím mě nenapadá jak takového chování docílit přirozeně v Blazor SSR. V režimu interaktivity by ale mohlo jít použít gRPC web. Nemám to teď vyzkoušené.
@@MirekHolec První volání StateHasChanged v tom příkladu s kočkama nepotřebujete - není tam změna stavu - komponenta ještě nebyla vykreslena dokud se to na tom prvním awaitu nevrátí
@@petrotych Je to tak, to mi uteklo. Díky za upozornění pro ostatní.