28 dicembre 2023 10:14

Meteo-AltoAdige 2.0 riscritto con Blazor .Net 8

Era il 2019 quando nel tardo autunno usciva la RTM di Blazor e .NET 3.1 e visto che mi frullava in mente l’idea di usarlo come tecnologia principe di un grosso progetto che sarebbe partito qualche mese dopo (l’informatizzazione del processo di selezione dell’Esercito, oggi Marina e in futuro altre Forze Armate), decisi di utilizzarlo per un progetto “reale” un po’ più complicato della solita demo.

Nacque quindi meteo-altoadige.it 1.0 (qui le esperienze del tempo) una SPA che quasi quotidianamente uso per dare un’occhiata alle temperature o altre misurazioni delle stazioni meteo che mi interessano.

Come molti sanno con l’avvento di .NET 8 Blazor ha cambiato radicalmente faccia ed è stato integrato con il motore di Asp.NET Core Razor Pages per dare vita a nuove WebApps che potessero essere usate meglio anche per pagine “statiche” (server side rendered, SSR) o per meglio dire per pagine dove non serve l’interattività.

L’occasione per testare e imparare tutte le novità era quindi ghiotta e ho deciso di rimettere mano al progetto iniziale in pratica ripartendo da zero (il classico File, New Project..).

Sono partito da un layout/template un po’ più moderno non preoccupandomi se ci fosse dentro qualche JS di troppo, visto che il main layout (gli anziani come me direbbero “la master page”) può utilizzare script ad esempio per aprire/chiudere sidebars o menu in maniera meno complicata (come embedding del jsruntime) di prima.

Ho cercato di utilizzare più modalità diverse possibili tra le tante disponibili per “farmi del male” 😊 ovvero per scoprire quali difficoltà o impedimenti sorgono mischiando pagine normali, con o senza streamrendering, con o senza prerendering e combinando i 3 Interactive Rendermodes (Server, Wasm, Auto).

Se posso anticipare il giudizio conclusivo su Blazor 8 è che sicuramente è ancora di più una figata rispetto a prima, ma l’ecosistema si è terribilmente complicato e bisogna assolutamente testare vari scenari prima di trovare la giusta soluzione.

Se oltre alle combinazioni possibili (pagine intere SSR, Server, Wasm, Auto) ci aggiungiamo quella di pagine SSR con dentro componenti interactive (renderizzati in 3 modi diversi), ci aggiungiamo il fatto che le SSR possono avere l’attributo StreamRendering per emulare il pattern “loading-faccio vedere qualcosa finché carico e poi completo la pagina” e ci buttiamo dentro anche il “prerendering” che può essere acceso o spento, capite bene che la possibilità che qualcosa non funzioni in una delle varie combinazioni è molto alta (e per fortuna non avevo a che fare con Authorization/Authentication che è una bruttissima gatta da pelare con questo mix infernale).

Non per niente, come ho scritto qui, ho dovuto farmi un progetto di test con gli 8 modi per capire se quello che andavo a implementare avrebbe funzionato o no… (ad esempio, il classico <PageTitle> per settare a runtime il title della pagina funziona solo in certi casi e in altro no)

L’utilizzo di modalità miste Server e Wasm (o di quella Auto che le coniuga) impone ovviamente l’uso di una Razor Component Library shared visto che alcuni componenti ovviamente li vogliamo riutilizzare sia nelle pagine puramente server (quelle che utilizzano -tramite servizi- direttamente EF Core) che quelle client (che ovviamente attingono i dati da API).

A proposito di API: molti si lamentano che non esiste più il template della solution a 3 progetti (Asp.net core Hosted, Wasm e shared) ma con il progetto WebApp è sufficiente nella parte server aggiungere al program.cs

builder.Services.AddControllers();
…
app.MapControllers();

per tornare a ospitare dei controller MVC e quindi fare in modo che le pagine/componenti client chiamino un API “interna” con lo stesso URI (meno sbattimenti a configurare CORS).

Sempre per motivi didattici ho comunque sviluppato anche delle api stand-alone ovviamente in formato Minimal-API che con la versione 8 hanno secondo me raggiunto la maturità necessaria per soppiantare i vecchi controller. Resta ovviamente a noi organizzare il tutto in moduli (io uso la libreria Carter per lo scopo) per avere il codice ordinato e ben diviso.

Ovviamente il tutto condito da FluentValidation, Mapster, Health-check, Serilog con Seq e il nuovo fighissimo motore di Global Error Handling (per dire il corollario di cose che stanno dietro a una semplice MapGet).

Tornando al Front End la versione 1.0 si avvaleva delle librerie di componenti DevExpress, mentre questa volta ho utilizzato quella che ormai è la mia library standard che uso più spesso ovvero la Radzen (essendo free ha più senso per un progetto “no-profit”). Ho dovuto ovviare alla mancanza di un componente che simulasse la OptGroup della select html (una dropdown con in gruppi in pratica) rivolgendomi alla libreria commerciale Syncfusion che sul mercato è sicuramente la più completa (ma anche oscenamente cara!).

Sinceramente i componenti Chart di DevExpress erano più sofisticati a livello di responsiviness (le label dell’asse X ad esempio veniva renderizzato a 45° e cambiava lo step quando la risoluzione diminuiva, per non impaccarsi e rendersi illeggibile). Al momento mi tengo quelli di Radzen, visto che il sito comunque non è assolutamente pensato per una fruizione totale da smartphone o device “sm/md” per dirla alla bootstrap.

Devexpress molto più smart nella gestione delle label di Radzen

La mia paura più grande era che mischiare il css del template (che ha dentro customizzato quello di Bootstrap5) con quello di due librerie di componenti portasse al marasma totale; invece giocando un po’ sull’ordine di caricamento, tutto sommato e per fortuna non ho avuto grossi problemi di compatibilità cross-library.

A proposito… non so ancora decidermi su quale standard buttarmi: plain bootstrap, material design (old o v3) o fluent design?? Voi cosa preferite? Scrivetemelo nei commenti… (so che non lo farà nessuno, ma a scriverlo mi sono sentito molto youtuber/influencer 😊)

Ci sarebbero altre decine di particolarità da raccontare (solo sull’uso del LocalStorage si potrebbe scrivere un post intero), ma direi che può bastare.

Per altre info relative al progetto in sé, vi invito a leggere la pagina About e vi auguro un buon 2024 pieno di coding soddisfacente.