Blazor

No właśnie, tak się zastanawiam. Ale to masz rację, przy czym ja niestety w tej grze opieram się jednak o JavaScript trochę, bo muszę użyć jakiegoś tam silniczka do rysowania, animacji i innych takich, więc to nie będzie taki czysty komponent Blazorowy, tylko jednak trochę zaślepek na JavaScript, ale ogólnie jak najbardziej. No i to chyba fajne jest, że w sumie mamy te dwie opcje, tak? I teraz, jeżeli ktoś się decyduje, to może sobie wybrać, co go bardziej interesuje. Każde z tych podejść ma wady i zalety. A tak trochę wspomniałeś właśnie, że będziesz tego JavaScripta musiał użyć, to rozumiem, da się jakoś to połączyć, te światy? Czy jak się zdecyduje na Blazora, to już muszę wszystko w Blazorze, czy jakbym miał potrzebę tego JavaScripta, to mogę jakoś to integrować?

To w tej Blazorowym WebAssemblowym to jest prosto, bo my jesteśmy po stronie klienta, więc wiadomo wtedy, że wołasz w przeglądarce. Tak jest. Ja tam miałem taką sprawę, że ja muszę poczekać, aż ten UI się wyrenderuje po stronie klienta. I wtedy dopiero mogę wywołać ten JavaScript, jeśli dobrze pamiętam. I wtedy dopiero mogę w ogóle zwrócić do serwera mojego informację, że słuchaj, to jest Windows. I wtedy ten serwer jeszcze raz renderuje stronę, bo zmienił się state. I ja wtedy dopiero zwracam ten button do Windows Store'a.

No a z drugiej strony wtedy w WebAssembly trzeba uważać, bo będzie zżarło baterie, bo będzie się procesor w telefonie męczył, więc... Tak, no. Natomiast co jeszcze jest fajne, to jest właśnie... Ja trochę będę bronił koncepcji WebAssembly w tym sensie, że to offloadowanie kosztu jest super. W czasach też np. serverlessa, to co robię swoją grą, to jest po prostu... Ja w ogóle nie będę miał serwera do tej gry, ponieważ wszystko idzie do klienta i klient sobie tam gra. Jeżeli potrzebuje jakiś apiszonów, no to potrzebuje oczywiście, bo to jest gra multiplayer, to ja sobie hostuję Azure Functions, a dodatkowo całość hostuje Static Web Appsami, czyli płacę za nic właściwie, bo klient sobie będzie ściągał Blazorowe pliki i tyle, więc fajne jest to, że teraz mamy takie klocki, z których można to tak poukładać, no bo kiedyś po prostu musiałbym wyhostować ASP.NET Core'ową apkę i ona by sobie tam wszystko miała i bym płacił cały czas za godzinę za granie ludzi czy niegranie i tak dalej, tak?

Ciebie to nie interesuje, po prostu go sobie dodajesz do Razora i to się będzie rysować. A ten JavaScriptowy interop cały traktują jak taki advanced, w ogóle nie ruszaj, to tylko dla senior developerów z doktoratami i tak dalej. Żeby, broń Boże, nie tworzyć takiego wrażenia, że to jest ich podejście, więc też może warto, żeby to brzmiało. Ja to tylko robię dlatego, że to do gier, co używam takiej biblioteczki, no to ona nie jest opakowana w żaden komponent blazorowy, więc sam to muszę tak jakby robić. W sensie sam opakowujesz komponent? Tak. Na przykład Chart.js, taka popularna biblioteka do rysowania wykresów, jest już opakowana i po prostu ściągasz sobie z Nuggeta Chart.js WebAssembly czy tam Blazor i masz.

Dodajesz jako Razora i konfigurujesz tego już potem z C-Sharpa i wszystkie propertasy i tak dalej robisz z C-Sharpa. Ok. Ciekawe. Ja mam pytanie z Trello, ale może Jarek, jeszcze masz jakieś pytania? Nie, nie, nie. Ja pamiętam, że też się odbiłem na autoryzację albo chyba na Bootstrapie, żeby to sensownie posklejać, bo właśnie coś brakowało. Nie chciał się ten Blazor komunikować z JavaScriptem, ale to było za dwa lata temu chyba. Coś klikałem i wtedy być może nie było tych komponentów, o których mówisz, Konrad, teraz... Dwa lata temu to raczkujące było jeszcze. Zresztą nadal trochę jest, więc... A to nie jest trochę tak, że... Trochę tak jak z Chocolaty, że Że musi być środowisko, które będzie opakowało te wszystkie swoje moduły w Blazorowe komponenty, bo inaczej właśnie trzeba będzie być seniorem z doktoratem?

Czy Microsoft ma jakiś automata? Pytam, bo wychodzi ten chart, czy coś innego? I kto się zajmuje opakowaniem tego w Blazora Microsoft? Ktoś kto zna JavaScripta i C-Sharpa, full stacki generalnie. Ale ogólnie dany producent, tak jakby oni mają w obowiązku wystawić, bo nie ma tak, że Microsoft dostarcza jakieś tak opakowane Blazorowe komponenty. Pewnie dostarcza jakieś swoje, tak, standardowe, a wszystko co ekstra, to jeżeli na przykład ten Chart.js by nie wystawił, to albo ja to muszę sam zrobić, albo poczekać aż wystawią, tak? Dokładnie. Coś takiego.

I sam też bym mógł, tak jakby nie muszę mieć jakichś Powiedzmy, dostępu do, nie wiem, powiedzmy źródeł, ale teoretycznie pewnie do źródeł Chart.js'a mam, ale mógłbym tak jakby zrobić taki komponent Blazorowy, wystawiający tego Chart.js'a? Czy muszę faktycznie być tym? Okej. Nie, nie, to tylko musisz rozumieć w miarę Czajdesa, dodać jakiś tam bootstrapowy JavaScript, który go startuje, opakować to w Blazor, a także to nawet nie potrzeba jakiegoś seniora do tego, myślę, że każdy ogarnięty Meet, powiedzmy, to zrobi. O, już do Meet'a zeszliśmy, dobra, jeszcze trochę i się nadam. Dasz radę, Paweł. Dobra, a tak jakby powiązane pytanie może właśnie, a jak wygląda taka właśnie sytuacja odnośnie tych komponentów?

Jest tego trochę, czy faktycznie jakbym chciał cokolwiek użyć, to będę się odbijał, że raczej nie ma Blazorowych? Wydaje mi się, że jest zaskakująco dużo jak na niedojrzałość tej technologii. Jest taka strona Awesome Blazor, gdzie tam można sobie zobaczyć status wielu tych kontrolek. Sporo jest takich darmowych setów kontrolek. Na pewno też te wszystkie Teleriki, DevExpressy już też to udostępniają, gdybyś bardzo chciał. A da się zablokować ten cały proces, żeby oni nie byli kompatybilni z Blazorem? Niestety nie chyba. Ty tylko możesz nogami zagłosować, nie kupując. No i uciekła mi myśl. Pytanie było jakie właściwie? Jak wygląda community tych, w sensie, czy jest tego sporo, czy raczej, wiesz, jeden na dziesięć szukanych?

Wydzieliłem taką logikę główną aplikacji, całe inputy, interakcje do tego view modelu, a taki kod specyficzny dla np. Blazora to zapakowałem już do widoków Blazorowych bezpośrednio. Taki kod np. jak nie wiem, co się stanie, jeśli w URL-u mam taki parametr lub taki. To akurat siedzi tam już w widoku, ale generalnie ja ten kod mam tak wydzielony w ten sposób, także odpowiadając na twoje pytanie, no to da się to zrobić tak, żebyś miał tą logikę oddzieloną od UI'a i możesz sobie później testować łatwo tą logikę. Ale to powiem od razu, to jest server-side'em. Nie wiem jak z WebAssembly. Możliwe, że się da, ale może być tak, że np. tam MVVM Cross może się nie odpalić, tak?

Ja robię to tak, że mam po prostu klasę ViewModel, którą injectuję sobie do tego page'a. I ja jedyną metodę taką blazorową, z której korzystam, no to tam jest StateHasChanged i ona mówi o tym, że UI się zmienił i serwerze weź zobacz, co tam się zmieniło i wyślij ten div do klienta, jeśli coś się zmieni. Także ja się podpiąłem pod view modelowe onPropertyChanged, także No jak, jeśli jakakolwiek propertia mi się zmienia, ja nawet nie patrzę, która, tylko po prostu lecę, cały state has changed. Boję się o performance penalty jakieś, jeśli tam jest, ale no ja generalnie jeszcze nie zauważyłem, żeby ta apka mi mocno zamulała.

Jak teraz ma się Maui, ukośnik Zamarine do Blazora? To jest coś, co też zaprzątało moją głowę jakiś czas, bo zaczyna się człowiek gubić w tym wszystkim. Ja na ten moment rozumiem, że to jest coś, co jest nadbudowane. To jest model, który jest jakąś tam ewolucją za Marine Formsów i teraz możesz sobie też Na fundamencie Maui budować Blazorową desktopową aplikację, czyli wsadzić tam komponent, który będzie w ten sposób rysował ci rzeczy. Czyli jedno jest zbudowane na bazie drugiego. Bo to co robi tak naprawdę Blazor Desktop to jest osadzenie widoku przeglądarki w aplikację.

że ty na swoim głównym serwerze aplikacji zamiast tych połączeń 20 tysięcy, no to masz tylko 5 per każdy SignalR Service. Tak się skaluje, także na pewno dzięki temu też będą mogli sprzedawać więcej Azure'a. No i może ten z Damarin. Jakoś to tam się wklikowuje w cały obraz. Nie, no na pewno, tylko tak mówię, ja byłem nie do końca pewnie zorientowany w tej całej siatce połączeń międzytechnologicznych. Jedno, co jeszcze nie wybrzmiało, a pewno warto powiedzieć, to nad czym teraz Microsoft mocno pracuje właśnie do dotneta szóstego, to żeby dodać IoT do Blazor WebAssembly, czyli teraz zyskujemy na prędkości, bo to może też warto podkreślić, że co to teraz się dzieje, jak uruchamiamy aplikację WebAssembly Blazorową,

I to jest mega moc. Może to nie wybrzmiało dostatecznie mocno, ale to jest ta zaleta. Nie wszystko jest w C Sharpie, wszystko jest w jednym projekcie. Jak nawet tworzysz ten serwer lesowy, projekt Blazorowy, to masz tam projekty Apisonów Azure Functions, masz projekt klienta w Blazorze i bibliotekę po prostu z klasami, która jest referencowana przez oba i tyle. Tak w ogóle ci tam nie obchodzi, co tam pod spodem chodzi i czy to jest JSON, czy nie JSON. Tak, czyli tak jak w MPC, małpka model i właściwie masz, nie? I na poziomie kompilacji wiesz czy ci to pójdzie czy nie pójdzie. I wszystkie renamy, literówki idą od razu. Także to bardzo fajna rzecz. Trochę mnie kusi, szczególnie właśnie po tym preview szóstki, że to będzie takie, wiecie, obiecują góry.

Ale, no co trzeba pamiętać, to też żeby mieć trochę więcej RAMu, zależy jak duży mamy state aplikacji. No i ja miałem akurat taki problem, że aplikacje mobilne, akurat kiedy zrobiłem tą łapkę jako PWA, podatki WTF, miałem taki problem w aplikacjach mobilnych, w przeglądarkach mobilnych raczej, Kiedy na przykład user na iOS-ie on sobie znawigował gdzieś dalej, nie wiem, wyłączył Safari, czy przełączył się do innej apki, czy przełączył się na inną kartę i po chwili wrócił na mój serwer, znaczy na moją stronę blazorową na podatki WTF, to miałem tam taki problem, że ten state aplikacji został wtedy już usunięty.

To wystarczy na to chyba 15 minut czy coś takiego. State aplikacji po stronie serwera został usunięty, no i ja wtedy muszę przeloadować, przekalkulować jeszcze raz ten state. Tam miałem taki problem, bo w tym frameworku Blazorowym zrobili coś takiego, że oni najpierw Robili sobie delay chyba 5 sekund, zanim podejmowali w ogóle jakiekolwiek połączenie, tak? Także user musiał później albo, nie wiem, czekać te 5 sekund, albo zrefreszować sobie apkę ponownie, jeśli wracał do niej po jakimś czasie. No ale generalnie jeśli ktoś się boi na przykład takich problemów, to wydaje mi się, że to też się da łatwo jakoś załatwić, bo ja na przykład dodałem tam kod do Blazora, do tego frameworka.

Perspektywy są niezłe, zwłaszcza, że jeszcze cały czas jest ten desktop, mobile, więc gdzieś się tworzy jakiś taki bardzo szeroki węczwach, ale aż możliwości, jak to będzie używane kiedyś. Ale czy to będzie używane? Nie wiem. Jeszcze pytanie mam ostatnie, mam nadzieję, że ostatnie. A czy jest możliwe, żeby mieć solucje i w tym projekty mieć na mobilki, na desktopa i na weba jednocześnie i jakoś tak się wspólnie wykompilować na wszystkie te targety? W sensie te blazorowe, tak? Tak, tak. Żeby właśnie mieć takiego blazora i tylko po prostu go targetować na różne, wiecie, markety, nie? Obstawiałbym, że taki będzie cel. No nie wiem, czy to już jest możliwe, zwłaszcza, że ten desktop jest w preview chyba jeszcze, ale reużywalność tutaj zdecydowanie.