In questo articolo troverete tutte le regole seguite da Razor riguardo la corretta scrittura del markup nelle nostre pagina Blazor.
Razor è un Template Markup Syntax, ed è lui che ci da la possibilità di includere codice eseguibile in una struttura HTML. Ci basta analizzare il semplice template iniziale di una applicazione Blazor per trovare “intrusioni” nel codice HTML.
<h1>Ciao! @nome</h1>
@if(nome != null)
{
<h1>Ciao @nome</h1>
}
@foreach(var user in users)
{
<p>@user.Name</p>
}
Questi alcuni esempi di markup. Questo articolo invece è dedicato alle assegnazioni di attributi e parametri di un componente. Ricordiamo che gli attributi sono proprietà già esistenti negli elementi HTML, mentre i parametri sono proprietà dei componenti del framework.
<td colspan=”4”></td>
Il motore Razor analizza tutto il codice scritto (HTML e linguaggio) per generare un HTML da usare per le operazioni di aggiornamento UI. Esempio:
<td colspan=@colSpan></td>
Viene trasformato in
<td colSpan=”4”></td>
Ecco un esempio di trasformazione di un nostro eventuale componente:
da:
<AppHeader Text=@headerText />
a:
<h1>Hello World!</h1>
Detto questo, passiamo all’argomento principale di questo articolo: come e quando usare la @, le virgolette e le parentesi.
Spesso c’è confusione nel markup, non si tratta di errori, ma semplicemente Razor accetta anche markup diversi.
Ad esempio, riprendendo il componente AppHeader
<AppHeader Text=”Hello World!” />
In questo caso stiamo passando come valore una costante string e sono quindi necessarie le virgolette.
<AppHeader Text=@headerText />
<AppHeader Text="@headerText” />
Nel caso di variabili, le virgolette non sono necessarie, ma Razor agisce nello stesso modo precedente se all’interno di esse trova la @. Meglio dirgli subito che la nostra intenzione e di usare una variabile senza affaticarlo con le virgolette. Anche nel caso di invocazione di un metodo, le virgolette non sono necessarie.
<AppHeader Text=@GetTitle() />
Se invece abbiamo bisogno di una operazione nell’assegnazione, allora questa va avvolta tra parentesi tonde.
<AppHeader Text=@($”{GetTitle()} Man”) />
<td colspan=@(colSpan * 2)></td>
Se c’è da valorizzare un parametro string, Razor in automatico invoca il metodo ToString() sull’oggetto complesso passato.
class User
{
public string Name { get; set; }
public string Surname { get; set; }
public override string ToString() => $”{Name} {Surname}”;
}
<AppHeader Text=@currentUser />
con il risultato
<h1>Mario Rossi</h1>
oppure
<input value=@currentUser />
con il risultato
<input value=”Mario Rossi” />
Nel caso di un componente <UserView User=@currentUser /> , essendo il parametro di tipo User l’istanza viene assegnata normalmente. Razor tenta di effettuare conversioni o estrazioni dalle virgolette cercando di poter soddisfare il parametro preso in considerazione in base al suo tipo.
<UserView Visible=true />
<UserView Visible=”true” />
<UserView Visible=@true />
<UserView Visible=”@true” />
Tutte e quattro le versioni vengono correttamente interpretate da Razor anche se abbiamo assegnato il valore di Visible con quattro modi differenti:
- true – viene vista come una costante string e vale come la seguente
- “true” – costante string analizzata da Razor
- @true – semplice valutazione dell’espressione
- “@true” – valutazione espressione racchiusa tra virgolette
Come ben sappiamo i componenti Razor vengono convertiti in classi durante la compilazione, ecco perché possiamo tranquillamente usare classi “partial” per separare la parte markup da quella codice C#. La pagina da noi descritta nel markup viene ricostruita tramite codice C#. Ecco perché le assegnazioni vanno fatte correttamente (l’intellisense quasi sempre ci avvisa di eventuali errori di distrazione). Ad esempio:
<AppHeader Visible=@HeaderVisible />
<AppHeader Visible="HeaderVisible” />
<AppHeader Visible=HeaderVisible />
Nella riga 2 Razor vede se nel codice c’è una variabile con nome “HeaderVisible”; nel caso la usa altrimenti ci pensa l’intellisense ad avvisarci. Mentre nella riga 3, prendendo una regola dell’HTML, valuta l’elemento a destra dell’operatore come se fosse racchiuso tra virgolette e quindi esegue l’operazione come per la riga precedente.
Poi ci sono le direttive che i componenti o elementi HTML possono avere. Poiché il valore assegnato ad una direttiva è fortemente tipizzato, tale valore verrà sempre interpretato come una espressione, per cui la @ non è necessaria se non per sostituire le virgolette. Alcuni esempi di direttive:
<button @onclick=AddUser />
<button @onclick=”() => DeleteUser(user.Id)” />
<button @onclick=@(() => DeleteUser(user.Id)) />
<InputText @bind-Value=model.Nome />
Per chi iniza una buona regola potrebbe essere quella di usare una sola @, o sinistra dell’operatore in caso di direttiva o a destra in caso di espressione.
Nota: In Blazor tutti gli eventi sono vincolati ad attività asincrone. Per invocare metodi async l’uso di async/await nel markup è inutile. Esempio errato:
<button @onclick=”async () => await DeleteUserAsync(user.Id)” />
Spero vi sia utile.
Alla prossima!
Scritto da:
