DEV Community: Stefano Marchisio (sviluppatore freelance)

Introduzione ad Angular

Stefano Marchisio (sviluppatore freelance) — Tue, 02 Feb 2021 20:34:23 +0000

Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

In questo Angular tutorial verranno trattati: Data Binding | decoratori @Input, @Output | decoratori @ViewChild, @ViewChildren, @ContentChild, @ContentChildren | content projection | manipolazione del DOM

Angular è un framework per lo sviluppo di SPA a componenti ed è una riscrittura completa di AngularJS. È stato rilasciato per la prima volta a maggio 2016 e la versione finale è stata rilasciata il 14 settembre 2016.

Angular ha molti miglioramenti rispetto ad AngularJS e presenta molte innovazioni che semplificano l'apprendimento e lo sviluppo di applicazioni enterprise.

In un applicazione Angular ogni elemento che vediamo nella UI è un component, ed un componente può essere a sua volta inserito all’interno di un altro componente formando così una struttura ad albero. In fase di progettazione è necessario quindi, scomporre la UI che desideriamo costruire in sotto componenti che svolgono una specifica funzione. Questo facilità in seguito eventuali modifiche oltre al riutilizzo del codice.

Il presente articolo è una raccolta di link che introducono e trattano alcuni aspetti base di Angular ( Slide - GitHub ).

1) Angular Component Communication (Data Binding) – parte 1

2) Angular Component Communication (decoratori @Input, @Output) – parte 2

3) Cosa sono le Template Reference Variable e i decoratori @ViewChild @ViewChildren @ContentChild @ContentChildren in Angular

4) Cosa sono le “projection” in Angular (ng-content ContentChild ContentChildren)

5) Come manipolare il DOM da un applicazione Angular

Ogni componente Angular ha poi degli eventi che vengono scatenati in determinati momenti, per esempio quando vengono inizializzate le proprietà di input piuttosto che quando il componente ed i relativi figli sono stati creati. E' opportuno utilizzare gli eventi del life-cycle di un componente nel modo appropriato onde evitare di incorrere in errori, maggiori informazioni al riguardo le potete trovare qui.

Se volete contattarmi il mio profilo Linkedin è il seguente:
Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Come manipolare il DOM da un applicazione Angular

Stefano Marchisio (sviluppatore freelance) — Tue, 02 Feb 2021 17:25:15 +0000

Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Quest'articolo spiega come manipolare il DOM in Angular attraverso le “Directive attributo” e le “Directive strutturali” piuttosto che lavorare a basso livello usando “Renderer2” e “ViewContainer” (ElementRef, TemplateRef, ViewContainerRef)

Introduzione

In un ottica web un developer è abituato a manipolare il DOM in un certo modo. Per esempio, creando lato client del codice HTML per poi inserirlo nel DOM tramite delle API JQuery, piuttosto che fare una chiamata AJAX che ci restituisca del codice HTML. Esiste poi l’opzione di far ritornare dati in formato JSON che verranno poi renderizzati tramite una delle tante librerie di template. Con Angular la manipolazione del DOM non avviene in questo modo, questo può essere causa di disagio soprattutto all’inizio in cui uno inizia a lavorare con Angular. In quest’articolo vediamo il perché, e come possiamo fare a manipolare il DOM utilizzando le API fornite da Angular.

Iniziamo col dire che Angular è un framework a componenti e di solito troviamo 3 file per ogni componente: un file .ts , un file .css e un file .html che rappresenta il template del componente. All’interno del template oltre all’HTML classico troviamo anche degli attributi/direttive di binding che servono a legare il template HTML al file TypeScript corrispondente, in questo modo la UI verrà automaticamente aggiornata nel momento in cui si cambia il valore di una delle proprietà del file TypeScript.

Per questo motivo altre alla compilazione TypeScript esiste anche una seconda compilazione Angular. Infatti in Angular è presente anche un compilatore, e questa può avvenire in modalità JIT piuttosto che AOT. Lo scopo di tale compilazione è tradurre l’HTML e gli attributi/direttive di binding presenti nel template in qualche cosa comprensibile dal framework. Senza entrare troppo nel dettaglio per ogni componente viene anche creata una classe di “ChangeDetection” che rileva eventuali modifiche (confrontando i vecchi valori con i nuovi), al verificarsi ci certi eventi.

Da questo si evince che il DOM è generato da queste classi (che non sono direttamente utilizzate dallo sviluppatore). Inoltre il collegamento tra questa famiglia di classi ed il DOM è unidirezionale, infatti se manipolo il DOM alla vecchia maniera (per esempio eliminando un nodo), la classe di “ChangeDetection” corrispondente non se ne accorge e continua a fare il suo lavoro. Ciò alla lunga può causare dei problemi di vario genere (in particolar modo prestazionali).

Tutto questo per spiegare il perché con Angular si deve procedere in modo diverso nella manipolazione del DOM da come siamo abituati a fare di solito. Nello stesso tempo Angular fornisce diversi strumenti/API per lavorare con il DOM in modo sicuro.

Come facciamo

In Angular abbiamo 2 strade per fa ciò

1) Usare le “Attribute directive” e “Structural directive” buld-in all’interno del framework che rendono tale cosa estremamente semplice

2) Lavorare ad un livello più basso usando: “Renderer2” e “ViewContainer

Direttive “Attribute directive” e “Structural directive”

In Angular esistono 2 famiglie di direttive buld-in che servono per manipolare il DOM in modo semplice e sicuro, ognuna di queste 2 famiglie è poi specializza per lavorare con gli attributi di un elemento piuttosto che aggiungere o rimuovere elementi.

Le “Attribute directive” appartengono alla prima famiglia e servono per lavorare con gli attributi di un elemento. In Angular ne esistono 2: “ngClass” e “ngStyle”. Con la prima è possibile aggiungere o rimuovere classi css da un elemento, con la seconda e possibile creare o rimuovere proprietà css da un elemento. Ogni direttiva può poi essere messa in binding con una proprietà all’interno del file TypeScript, in modo che i valori vengano settati in modo dinamico (sotto un esempio di ngClass).

Le “Structural directive” appartengono alla seconda famiglia e servono per aggiungere o rimuovere elementi dal DOM. In Angular ne esistono 3: “ngIf”, “ngFor”, “ngSwitch”. Come si evince dal nome, con la prima è possibile creare degli elementi in modo condizionale, con la seconda è possibile renderizzare una lista di elementi, con la terza è possibile creare degli elementi in modo condizionale tramite un’istruzione di switch. Tutte le direttive strutturali possono essere messe in binding con proprietà contenute all’interno del file TypeScript (sotto un paio di esempi).

Come si può notare le direttive strutturali sono precedute con un “*” davanti al nome, infatti vengono scritte come: *ngIf, *ngFor, *ngSwitchCase (questa è una “syntax sugar”). Come detto all’inizio dell’articolo, oltre alla compilazione TypeScript esiste anche una seconda compilazione Angular che lavora principalmente sui template HTML.

Una direttiva “ngIf” come quella sottostante

Viene tradotta in questo modo dal compilatore

Questo per rendere più agevole la scrittura di codice, ma se scrivessimo un “ngIf” nel secondo formato il tutto funzionerebbe senza problemi. Per maggiori informazioni in merito alle direttive build-in si rimanda alla documentazione del framework.

“Renderer2” e “ViewContainer”

Fino ad ora abbiamo visto come possiamo manipolare il DOM usando le direttive build-in presenti nel framework, ma nel caso queste non bastassero dobbiamo iniziare a lavorare ad un livello più basso ed è in questo caso che entrano in gioco “Rendere2” e “ViewContainer”.

“Rendere2” viene usato quando vogliamo lavorare con gli attributi di un elemento.

“ViewContainer” viene usato quando vogliamo aggiungere o rimuovere degli elementi.

Prima di continuare dobbiamo fare una premessa per capire meglio quello che verrà dopo. Abbiamo detto che Angular è un “framework per lo sviluppo di applicazioni web” più comunemente dette SPA. Gli sviluppatori di Angular non si sono solo prefissati che un applicazione possa essere eseguita all’interno del browser, ma che possa anche essere eseguita in un web-workers o server-side. Detto ciò, in alcuni momenti un browser come lo intendiamo noi potrebbe non essere presente, per cui hanno introdotto una serie di astrazioni e “Render2” è appunto una di queste.

“Renderer2”

ElementRef: fornisce una referenza ad un elemento del DOM, può essere iniettato nel costruttore di un componet / directive oppure letto tramite: @ViewChild(), @ViewChildren. Nel caso la iniettiamo nel costruttore di una direttiva fornisce una referenza all’elemento sul quale la direttiva è applicata.

Rendere2: è un astrazione al DOM per non incorrere agli effetti server-side o web-workers, di norma tale classe è iniettata nel costruttore di un componet / directive.

Queste classi lavorano insieme (Rendere2 lavora sul DOM mentre ElementRef è una referenza ad un elemento del DOM). Sotto possiamo vedere il codice di una semplice direttiva.

Come si può vedere manipolare il DOM con “Rendere2” non è più complicato che manipolare il DOM direttamente, inoltre “Rendere2” contiene una serie metodi con i quali è possibile effettuare le principali operazioni sugli attributi: setAttribute(), removeAttribute(), addClass(), removeClass(), setStyle(), removeStyle().

“ViewContainer”

La prima cosa da dire è che ogni elemento del DOM può essere usato come ViewContainer, inoltre Angular non inserisce il contenuto all’interno di un ViewContainer ma lo appende dopo. Un candidato ideale come ViewContainer può essere l’elemento “ng-container”, questo perché viene renderizzato come commento evitando di inserire nel DOM elementi ritondanti. Un ViewContainer possiede vari metodi tra cui: createEmbeddedView() e createComponent(). Con questi metodi è possibile creare EmbeddedView e HostView, le prime sono create usando come modello un “Template” le seconde sono create usando come modello un “Component”.

ViewContainerRef: rappresenta un contenitore o placeholder dove una o più viste possono essere attaccate. Può essere iniettato nel costruttore oppure letto tramite: @ViewChild(), @ViewChildren(). Se iniettato nel costruttore di un componente, rappresenta il componente stesso.

TemplateRef: rappresenta il template con cui è possibile creare un EmbeddedView. Può essere iniettato nel costruttore (nel caso si tratti di una direttiva custum) oppure letto tramite: @ViewChild(), @ViewChildren().

Sotto si può vedere un esempio di codice di un EmbeddedView (ovvero view che usano come modello un template).

Come si può vedere abbiamo un div / #container1 ed un template #tpl1. All’interno del componente tramite @ViewChild() vengono lette le reference di questi 2 elementi e all’interno del metodo ngAfterViewInit() viene creata l’EmbeddedView tramite il metodo this.vcr1.createEmbeddedView(this.tpl1). Da notare che l’ EmbeddedView è stata creata all’interno del metodo ngAfterViewInit() perché le reference recuperate tramite @ViewChild() sono disponibili dopo questo evento, prima avrebbero valore undfined se stiamo usando componenti dinamici. Con Angular 8 le cose cambiano leggermente, maggiori informazioni quì.

Ciò vale tutte le volte che si utilizza @ViewChild(), @ViewChildren (), etc. In questo modo il codice HTML contenuto nel template viene inserito in modo sicuro all’interno del DOM. La classe ViewContainer fornisce inoltre una serie di altri metodi tra cui clear(), con cui è possibile rimuovere il codice HTML del template dal DOM.

Sotto si può vedere un esempio di codice di un EmbeddedView (ovvero view che usano come modello una direttiva strutturale custom).

Come si può vedere, all’interno del nostro componente abbiamo 2 bottoni (uno per creare e l’altro per rimuovere) ed una direttiva strutturale custom contenuta in un div.

Come menzionato sopra, la direttiva viene tradotta dal compilatore in questo modo

All’interno del codice TypeScript della direttiva, vengono iniettati nel costruttore il ViewContainerRef ed il TemplateRef. In questo modo quando premiamo i bottoni di creazione e rimozione vengono chiamati rispettivamente i metodi del ViewContainer: this.vcr.createEmbeddedView(this.tpl) e this.vcr.clear(). Come si può vedere il codice di una direttiva strutturale è abbastanza simile al codice utilizzato per creare un EmbeddedView all’interno di un componente. Il vantaggio è che in questo modo ho un maggior riutilizzo del codice oltre al fatto di separare le responsabilità Component / Directive.

Sotto si può vedere un esempio di codice di un HostView (ovvero view che usano come modello un Component).

In questo esempio abbiamo scelto di utilizzare come modello un componente (ovvero vogliamo creare un HostView). Non essendo possibile istanziare il componente direttamente con una new dobbiamo crearlo utilizzando la factory relativa al componete. Per far ciò, all’interno del costruttore iniettiamo il servizio “ComponentFactoryResolver” e poi tramite questo servizio creiamo la factory del componente che vogliamo creare. Infine tramite il metodo createComponent(factory) del viewcontainer creiamo il nostro componente passando come parametro la factory appena creata. In questo modo il codice HTML contenuto nel componente viene inserito in modo sicuro all’interno del DOM. La classe ViewContainer fornisce inoltre una serie di altri metodi tra cui clear(), con cui è possibile rimuovere il codice dal DOM.

ngTemplateOutlet e NgComponentOutlet

Fino ad ora abbiamo utilizzato le api fornite da ViewContainerRef: createEmbeddedView() e createComponent(); per creare EmbeddedView e HostView utilizzando un approccio imperativo da codice, ma Angular ci mette anche a disposizione delle direttive strutturali per fare la stessa cosa in modo dichiarativo. Queste direttive sono usate frequentemente con ng-container, ma possono anche essere applicate ad un elemento html.

In questo esempio è stata utilizzata la direttiva “ngTemplateOutlet” all’interno di un ng-container, passando come parametro la template reference variable che identifica il template da renderizzare. Come si può vedere non è stato necessario utilizzare nessuna delle api degli esempi precedenti, rendendo la cosa molto più veloce! Anche se non mostrato nell’esempio, è anche possibile definire e passare al template un context contenente delle variabili.

In questo esempio è stata utilizzata la direttiva “ngComponentOutlet” all’interno di un ng-container, passando come parametro la variabile compfirst tipizzata come CompFirstComponent. Come si può vedere non è stato necessario utilizzare nessuna delle api degli esempi precedenti, rendendo la cosa molto più veloce! Anche se non mostrato nell’esempio, è anche possibile definire e passare al componente che verrà creato un injector sul quale sono stati registrati dei servizi.

Come si può vedere l’utilizzo delle direttive strutturali “ngTemplateOutlet” e “ngComponentOutlet” permettono la creazione di EmbeddedView e HostView in modo dichiarativo, senza la necessità di richiamare le api degli esempi precedenti.

Conclusioni

Fino ad ora sono state utilizzate le API presenti nel framework. Cose analoghe possono anche essere fatte utilizzando gli “Overlay” presenti in “Angular Material”, ma non è lo scopo di quest’articolo.

1) Introduzione ad Angular / Sommario

2) Angular Component Communication (Data Binding) – parte 1

3) Angular Component Communication (decoratori @Input, @Output) – parte 2

4) Cosa sono le Template Reference Variable e i decoratori @ViewChild @ViewChildren @ContentChild @ContentChildren in Angular

5) Cosa sono le “projection” in Angular (ng-content ContentChild ContentChildren)

6) Come manipolare il DOM da un applicazione Angular

Se volete contattarmi il mio profilo Linkedin è il seguente:
Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Angular Component Communication (Data Binding) – parte 1

Stefano Marchisio (sviluppatore freelance) — Tue, 02 Feb 2021 17:24:56 +0000

Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Quest'articolo mostra i 4 tipi di databinding presenti in Angular: Iterpolation, Property binding, Event binding, TwoWay binding

Angular è un framework per lo sviluppo di SPA a componenti. Di solito un componente è composto da 3 files: un file .ts , un file .css e un file .html che contiene il template HTML del componente, ma volendo è anche possibile definire tutto in un unico file .ts, sarà responsabilità dello sviluppatore scegliere l’approccio che preferisce. Per cui ogni elemento che vediamo nella UI è un componente ed un componente può essere a sua volta inserito all’interno di un altro componente, formando così una struttura ad albero. In fase di progettazione è necessario quindi, scomporre la UI che desideriamo costruire in sotto componenti che svolgono una specifica funzione. Questo facilità in seguito eventuali modifiche oltre al riutilizzo del codice. Eventualmente, se il progetto è di grandi dimensioni, è buona norma implementare anche pattern architetturali (per esempio stateful e stateless component).

Si ha quindi la necessità che i componenti possano comunicare tra loro:

1) Che il templete HTML possa comunicare con il codice TypeScript del componente corrispondente.

2) Un componente padre possa inviare dati a componenti figlio, così come un componente figlio possa inviare dati al componente padre sotto forma di eventi.

3) Che 2 o più componenti disgiunti possano inviarsi notifiche contenenti dati (RxJs Subject).

In questa serie di articoli vedremo i vari strumenti che Angular ci fornisce per fare ciò, iniziando con il “data binding”, per passare poi ai decoratori di ”@Input” “@Output” ed infine alle “Template Reference Variable”.

Data Binding

Con data binding si intende la capacità di un template HTML di comunicare con il codice TypeScript del componente corrispondente, in modo che la UI verrà automaticamente aggiornata nel momento in cui si modifica il valore di una delle proprietà nel file TypeScript.

A prescindere da Angular, esistono 2 modalità di comunicazione a seconda che questa avvenga in modo unidirezionale (“one way data binding”) o bidirezionale (“two way data binding”).

1) Nel data binding unidirezionale o (“one way data binding”) i dati viaggiano dal modello al template. Aggiornando una proprietà nel modello viene aggiornata in modo automatico l’interfaccia utente.

2) Nel data binding bidirezionale o (“two way data binding”) i dati viaggiano in entrambe le direzioni. Aggiornando una proprietà nel modello viene aggiornata in modo automatico l’interfaccia utente. Editando un elemento sull’interfaccia utente viene aggiornato il modello sottostante.

In Angular abbiamo a disposizione 4 tipi di data binding: Iterpolation, Property binding, Event binding, TwoWay binding. I primi 3 tipi di data binding sono unidirezionali, il quarto tipo di data binding è bidirezionale.

Interpolation data binding

L’ Intepolation data binding usa la seguente sintassi "{ { expression } }" per renderizzare all' interno del template HTML dati presenti nel modello. Con "expression" si intende sia una semplice proprietà presente nel codice TypeScript del componente, che un espressione JavaScript valida.

Property data binding

Il property data binding usa la seguente sintassi “[]” per mettere in collegamento il template HTML con il modello. Viene utilizzato per mettere in comunicazione una proprietà di un elemento HTML (o di un nostro componente) con una proprietà presente nel codice TypeScript del componente.

Interpolation data binding può essere un alternativa al property binding. Angular trasla interpolation data binding nel property data binding nel momento in cui compila il template HTML.

Event data binding

Quando un utente interagisce con la UI di un applicazione (muove il mouse, preme un tasto o un bottone) genera un evento, quest' evento deve poi essere intercettato e gestito nel codice TypeScript del componente. Angular fornisce inoltre la possibilità di creare eventi custom. I’ event data binding usa la seguente sintassi “()” per mettere in collegamento il template HTML con il modello.

Nell’esempio sovrastante si può vedere che l’evento che si desidera intercettare è tra parentesi tonde (a differenza del property data binding in cui si usavano le parentesi quadre). Tra doppi apici viene poi messo il metodo che deve essere chiamato, ed il parametro “$event” è una parola riservata di Angular e serve per passare l’evento originale al metodo (nel nostro caso MouseEvent).

L’esempio sovrastante è simile al precedente, l’unica differenza è che non viene passato “$event” come parametro ma bensì “car”. Infatti è anche possibile passare ad un event-handler una proprietà di data binding visibile dal template. Nel nostro esempio è presente un ciclo for che itera su una collezione cars. Per ogni elemento viene creato un bottone passando all’ event-handler l'oggetto car.

TwoWay data binding

TwoWay data binding usa la seguente sintassi "[()]" per renderizzare all’interno del template HTML i dati presenti nel modello ed aggiornare il modello nel momento in cui si edita l’interfaccia. Come si può vedere non è altro che l’insieme delle 2 sintassi (Property data binding e Event data binding ). Per poterlo utilizzare dobbiamo usare la direttiva “ngModel” contenuta nel modulo “FormsModule”.

Come si può vedere tra parentesi (quadrate e tonde) non si mette più la proprietà, ma la direttiva “ngModel”. La proprietà viene invece assegnata a ciò che abbiamo appena scritto e nel codice TypeScript del componente deve essere presente una proprietà “myfield”. In Angular il twoWay data binding non è poi così strategico perché esistono anche altre strade per poter aggiornare in dati.

Nell’esempio sovrastante all'evento "ngSubmit" è stata assegnata la funzione onSubmit(f) e come parametro viene passata la “Template Reference Variable” contenente direttiva ngForm. Questo mi servirà per recuperare i valori dei campi del form nel codice TypeScript del componente.

Nell’esempio compare anche una nuova sintassi: #f="ngForm". Questa è una “Template Reference Variable” e verranno trattate più avanti in questa serie di articoli.

1) Introduzione ad Angular / Sommario

2) Angular Component Communication (Data Binding) – parte 1

3) Angular Component Communication (decoratori @Input, @Output) – parte 2

4) Cosa sono le Template Reference Variable e i decoratori @ViewChild @ViewChildren @ContentChild @ContentChildren in Angular

5) Cosa sono le “projection” in Angular (ng-content ContentChild ContentChildren)

6) Come manipolare il DOM da un applicazione Angular

Se volete contattarmi il mio profilo Linkedin è il seguente:
Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Cosa sono le “projection” in Angular (ng-content ContentChild ContentChildren)

Stefano Marchisio (sviluppatore freelance) — Tue, 02 Feb 2021 17:05:13 +0000

Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Quest'articolo spiega il concetto di projection in Angular, l'uso del tag ng-content e come recuperare il contenuto proiettato attraverso i decoratori: @ContentChild @ContentChildren

Angular è un framework per sviluppare SPA a componenti. Ogni elemento che vediamo nella UI è un componente ed un componente a sua volta può essere inserito all’interno di un altro componente formando una struttura ad albero. Le projection sono un concetto molto importante in Angular, e servono a creare componenti scalabili e flessibili.

Come si può vedere abbiamo definito un semplice componente Angular che può essere riutilizzato tutte le volte che vogliamo inserendo il selettore < app-home> < /app-home> in un templete HTML. Come si può notare, pur avendo creato un componente riutilizzabile, non è molto flessibile perché le 2 righe di testo contenute nel template sono fisse così come i tag HTML. Per rendere la cosa più dinamica possiamo trasformarlo nel seguente modo.

Come si può vedere il testo è diventato dinamico, infatti viene passato tramite proprietà di input nel selettore < app-home>
< /app-home>. Il problema è che title e content hanno i rispettivi tag HTML,definiti all’interno del template dell’ HomeComponent, che rimangono fissi. Come possiamo fare se vogliamo che il title in alcuni casi sia visualizzato con H1 ed in altri con H2? Senza inserire delle istruzioni condizionali all’interno del template dell’ HomeComponent. La risposta è utilizzare le Angular “projection”.

Come si può vedere, oltre a passare dei dati ad un componente attraverso i parametri di input ( quelli definiti col decoratore @Input() ) è anche possibile passarli inserendoli tra il tag di aperture e chiusura di un componente. All’interno del componente troveremo poi un nuovo tag < ng-content> < /ng-content>. Questo nuovo tag è un placeholder ovvero definisce la posizione in cui inserire “testo” passato tra il tag di apertura e chiusura di un component. Ho detto “testo”, ma può anche essere uno spezzone di codice HTML composto da più tag, piuttosto che un altro componente angular. In quest’ esempio il content continua ad essere passato come parametro di input. Come possiamo fare invece per passare sia title che content all’interno del tag di apertura e chiusura?

Come si può vedere troviamo ora 2 ng-content, il tag ng-content possiede un attributo addizionale “select” che funziona in modo analogo ad un selettore CSS. Per cui ogni ng-content visualizzerà solo gli elementi che soddisfano il criterio specificato, che nel nostro caso è h1 e span. Essendo simile ad un selettore CSS funziona anche con classi CSS. Con questi semplici esempi abbiamo spiegato quello che in Angular è chiamato “projection”.

Nell’articolo riguardante le “Template Reference Variable” abbiamo introdotto i decoratori: @ViewChild(), @ViewChildren(), @ContentChild(), @ContentChildren(). In quell’articolo è stato spiegato che: i primi 2 ispezionano gli elementi che sono nel template HTML direttamente mentre i secondi 2 ispezionano gli elementi proiettati ovvero gli elementi presenti all’interno di < ng-content> < /ng-content>.

Anche se abbiamo già avuto modo di intuire alcune cose, approfondiremo ora come utilizzare i decoratori @ContentChild(), @ContentChildren() per ritrovare referenze di componenti proiettati. Sotto possiamo vedere 3 componenti: PageComponent, TabsComponent, TabComponent.

PageComponent

TabsComponent

TabComponent

Come si può vedere all’interno del componente PageConponent è stato inserito un componente TabsComponent, ed all’interno del tag di apertura e chiusura sono stati inseriti 3 componenti TabComponent. Nel momento in cui eseguiamo il codice, l’output è quello dell’immagine sottostante.

La posizione dell’output dei 3 componenti TabComponent (contenuti all’interno del tag di apertura e chiusura del componente TabsComponent) è determinata dai tag < ng-content> < /ng-content>. Nel nostro caso ne abbiamo 3 ed ognuno ha un attributo “select “ impostato sul valore di una classe CSS. In questo modo stabilisco nella posizione che voglio nel template HTML del componente TabsComponent, inoltre tra un < ng-content> < /ng-content> e l’altro può esserci altro testo (come nel nostro caso). Nel codice TypeScript dei primi 2 componenti possiamo notare altre cose interessati.

Nel componente PageComponent troviamo i seguenti decoratori

In questo modo children1 e children2 contengono le referenze del componente TabsComponent e dei 3 componenti TabComponent. All’interno del componente PageComponent, non essendo ancora stati proiettati uso il decoratore @ViewChild.

All’interno del componente TabsComponent, tanto per intenderci quello nel cui template HTML trovo i 3 < ng-content> < /ng-content>, i componenti TabComponent sono già stati proiettati. Per cui se voglio recuperare le loro referenze devo usare il decoratore.

Una cosa che vale per tutti i decoratori ( @ViewChild(), @ViewChildren(), @ContentChild(), @ContentChildren() ), il valore recuperato è disponibile dopo l’evento ngAfterViewInit. Prima di tale evento le variabili potrebbero avere valore undefined se stiamo usando componenti dinamici. Con Angular 8 le cose cambiano leggermente, maggiori informazioni quì.

Con quest’articolo si completa il discorso sull’ “Angular Component Communication” ovvero sulla necessità che i componenti possano comunicare tra loro.

1) Introduzione ad Angular / Sommario

2) Angular Component Communication (Data Binding) – parte 1

3) Angular Component Communication (decoratori @Input, @Output) – parte 2

4) Cosa sono le Template Reference Variable e i decoratori @ViewChild @ViewChildren @ContentChild @ContentChildren in Angular

5) Cosa sono le “projection” in Angular (ng-content ContentChild ContentChildren)

6) Come manipolare il DOM da un applicazione Angular

Se volete contattarmi il mio profilo Linkedin è il seguente:
Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Cosa sono le Template Reference Variable e i decoratori @ViewChild @ViewChildren @ContentChild @ContentChildren in Angular

Stefano Marchisio (sviluppatore freelance) — Tue, 02 Feb 2021 16:31:02 +0000

Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Quest'articolo mostra l'uso delle “Template Reference Variable” e come fare delle query DOM attraverso: @ViewChild @ViewChildren @ContentChild @ContentChildren per recuperare referenze

Template Reference Variable

Una “Template Reference Variable” è una referenza ad un elemento all’interno in un template HTML, e con elemento si intende sia un semplice elemento HTML che un altro componente o direttiva presente nel template HTML. Nel primo caso avremo una referenza ad un elemento del DOM (ed il tipo associato è ElementRef) nel secondo caso una referenza ad un componente o direttiva. Le “Template Reference Variable” vengono anche usate per definire template con cui creare EmbeddedView o per identificare ViewContainer all’interno dei quali creare EmbeddedView. Una “Template Reference Variable” viene dichiarata mettendo il carattere “#” davanti al nome (come fosse un attributo addizionale).

Nell'esempio sovrastante viene utilizzato un tag HTML, ma lo stesso discorso vale anche per un componente. Nel momento in cui dichiariamo una “TemplateReferenceVariable”, che per brevità in seguito chiameremo TRV, abbiamo accesso a tutte le proprietà e metodi definiti in quell’oggetto. Una “TRV” può essere utilizzata sia all’interno del templete HTML stesso ( per esempio in un espressione di binding "{ { } }" ) sia nel codice TypeScript di un componente. All’interno di un template HTML può anche essere passata come parametro ad un evento.

Sopra si possono vedere 2 esempi: una TRV definita in un elemento HTML e una TRV definita in un component. Se viene dichiarata senza essere inizializzata conterrà una referenza all’elemento o componente. Esiste anche una seconda modalità per dichiararla (vedi sotto).

In questo caso viene assegnato un valore alle TRV in fase di dichiarazione.

Per cui non conterrà più la referenza dell’elemento in cui è stata dichiarata, ma bensì conterrà l’oggetto che gli è stato assegnato (in questo caso la direttiva del FormModule). Nel caso di #f="ngForm", visto che la variabile viene passata ad un evento, nel codice TypeScript al metodo onSubmit(f) verrà passata la direttiva ngForm. Questo mi servirà per recuperare i valori dei campi del form.

@ViewChild(), @ViewChildren(), @ContentChild(), @ContentChildren()

All’interno del codice TypeScript di un componente una “TRV” dichiarata nel template HTML non è visibile ovvero se referenzio il suo nome nel codice otterrò un errore di compilazione. Ma Angular fornisce un meccanismo chiamato DOM query. Questa funzionalità permette di fare delle query all’interno del template HTML, per ottenere referenze a “Component”, “Directive” e “TRV” (definiti nel templete HTML). Per far ciò devo usare i decoratori @ViewChild(), @ViewChildren(), @ContentChild(), @ContentChildren() nella dichiarazione di una variabile.

I primi 2 decoratori: @ViewChild(), @ViewChildren() ispezionano gli elementi che sono nel template HTML direttamente.

I secondi 2 decoratori: @ContentChild(), @ContentChildren() ispezionano gli elementi proiettati ovvero gli elementi presenti all’interno di < ng-content>< /ng-content>

In entrambi i casi “Child” ritorna un solo elemento, mentre “Children” ritorna più elementi (nel caso la query trovi più elementi che soddisfano il criterio di ricerca).

Questi decoratori devono essere anteposti alla dichiarazione di una variabile, un po’ come avviene per i decoratori di @Input(), @Output(). Sarà poi Angular che in modo automatico effettuera la DOM query e metterà il risultato nella variabile. L’unica cosa da tener presente è che il risultato potrebbe esserci solo dopo l’evento “ngAfterViewInit”. Prima di tale evento la variabile sarà undefined, se stiamo usando componenti dinamici. Con Angular 8 le cose cambiano leggermente, maggiori informazioni quì. Il tipo di dato contenuto in questa variabile dipenderà invece da cosa stiamo leggendo (ElementRef, TemplateRef, ViewContainerRef, ComponentCustom, DirectiveCustom, etc…)

Fin qui abbiamo visto come recuperare un elemento facendo una DOM query con uno dei decoratori menzionati sopra: @ViewChild(), @ViewChildren(), @ContentChild(), @ContentChildren().

Ma esiste anche un’altra modalità! Ora, visto che tutti i componenti sono contenuti dentro un elemento custom del DOM e visto che tutte le direttive sono applicate ad elementi del DOM, componenti e direttive possono ottenere un istanza dell' ElementRef che li contiene tramite dependency injection.

Infatti dichiarando nel costruttore di un componente una variabile ElementRef, verrà passata tramite dependency injection la referenza dell’elemento che contiene il componente. Analogamente, dichiarando nel costruttore di una direttiva una variabile ElementRef, verrà passata tramite dependency injection la referenza dell’elemento a cui è applicata la direttiva.

ElementRef: fornisce una referenza ad un elemento del DOM. Può essere iniettato nel costruttore di un componet / directive oppure letto tramite: @ViewChild(), @ViewChildren.

TemplateRef: rappresenta il template con cui è possibile creare un EmbeddedView. Può essere iniettato nel costruttore (nel caso si tratti di una direttiva custum) oppure letto tramite: @ViewChild(), @ViewChildren().

ViewContainerRef: rappresenta un contenitore o placeholder dove una o più viste possono essere attaccate. Può essere iniettato nel costruttore oppure letto tramite: @ViewChild(), @ViewChildren().

Sotto un primo esempio

In quest’esempio è stata attribuita una “TRV” ad un tag span. Nel codice TypeScript invece, tramite il decoratore @ViewChild leggiamo il valore di questa referenza e la mettiamo nella variabile “tref”. Tale valore sarà poi disponibile nell’evento ngAfterViewInit.

La sintassi base per dichiarare un decoratore è la seguente.

Come si può vedere è stato specificato “tref” come “template reference”. Il secondo parametro invece non è sempre obbligatorio, infatti Angular tenta di inferirlo da ciò che stiamo leggendo.

Per cui il decoratore sopra avremmo potuto scriverlo nella forma abbreviata (essendo un semplice elemento HTML viene inferito come ElementRef).

Anche nel caso si debba leggere una “TRV” associata ad un < ng-template> è possibile usare la forma abbreviata (essendo un ng-template viene inferito come TemplateRef). Ci sono dei casi però in cui Angular non riesce ad inferire il tipo, per cui è necessario usare la forma completa. Un tipico esempio è ViewContainerRef.

In quest’esempio leggiamo un template #tpl1 che viene usato per creare un EmbeddedView da inserire nel ViewContainer identifcato dalla #container1. Come si può vedere abbiamo usato la forma abbreviata per leggere il template, mentre abbiamo usato la forma completa per leggere il viewcontainer. Maggiori informazioni sulla manipolazione del DOM è possibile trovarle nei prossimi articoli.

Sotto un secondo esempio

In quest’esempio invece di definire e leggere una “TRV”, leggiamo la referenza di un componente definito nel template HTML. Nel decoratore non verrà passata una stringa con un nome, ma bensì verrà passato il componente. Stesso discorso nel caso volessimo leggere una direttiva custom o una direttiva build-in.

1) Introduzione ad Angular / Sommario

2) Angular Component Communication (Data Binding) – parte 1

3) Angular Component Communication (decoratori @Input, @Output) – parte 2

4) Cosa sono le Template Reference Variable e i decoratori @ViewChild @ViewChildren @ContentChild @ContentChildren in Angular

5) Cosa sono le “projection” in Angular (ng-content ContentChild ContentChildren)

6) Come manipolare il DOM da un applicazione Angular

Se volete contattarmi il mio profilo Linkedin è il seguente:
Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Angular Component Communication (decoratori @Input, @Output) – parte 2

Stefano Marchisio (sviluppatore freelance) — Tue, 02 Feb 2021 16:07:57 +0000

Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Quest'articolo mostra l'uso dei decoratori di @Input, @Output per passare dati piuttosto che ricevere eventi.

Nella prima parte di quest’articolo abbiamo introdotto il concetto di data binding e come può essere implementato in Angular: Iterpolation, Property binding, Event binding, TwoWay binding. In questa seconda parte continuiamo il discorso sul’ “Angular Component Communication” e parleremo dei decoratori di @Input, @Output.

Angular à un framework a componenti, ed il template HTML di ogni componente può contenere al suo interno altri componenti in modo da formare una struttura ad albero. Detto questo nasce la necessità che i componenti siano in grado comunicare tra loro. In particolar modo che un componente padre possa inviare dati a componenti figlio, così come un componente figlio possa inviare dati al componente padre sotto forma di evento.

Questa funzionalità in Angular è fornita tramite decoratori di @Input(), @Output(). Un decoratore è una funzione preceduta dal carattere “@”, e deve essere posto in fase di dichiarazione prima di una variabile.

Sopra si può vedere un esempio di dichiarazione di un parametro di Input. Nella dichiarazione del parametro di Output assegniamo alla variabile l’oggetto “EventEmitter” (che può essere tipizzato). L’oggetto “EventEmitter” è un Observable e possiede un metodo “emit()”, questo metodo viene invocato quando vogliamo lanciare l’evento. Sotto possiamo vedere un esempio completo di 2 componenti: padre e figlio.

Parent Component

Child Component

Come si può vedere, nel template HTML del “Parent component” è stato dichiarato il “Child Component” , ed il tag ha una proprietà di binding “data” che rappresenta il parametro che vogliamo passare. All’interno del “Child Component” è stata poi dichiarata una variabile preceduta dal decoratore @Input(), questo fa si che Angular metta in questa variabile ciò che era presente nella proprietà di binding “data” del “Parent component”.

Per quanto riguarda i parametri di Output, nel “Child Component” è stata dichiarata una variabile preceduta dal decoratore @Output(). Nel momento in cui vogliamo sollevare l’evento basta richiamare il metodo “emit()” passando come parametro l’argomento che vogliamo ritornare. All’interno del “Parent component” devo infine dichiarare un event-handler che riceva tale evento.

I parametri di Input sono disponibili solo dopo l’evento ngOnInit e vengono aggiornati nel caso di modifiche. Nel nostro esempio troviamo un solo parametro di input, ma in un componente possono essere presenti n. parametri di Input. Come detto all’inizio Angular è un framework a componenti ed ogni componente ha un proprio “lifecycle” scandito da eventi che è possibile intercettare. Tra questi ngOnChanges(changes: SimpleChanges) notifica quando un parametro di Input viene modificato. Come si può vedere quest’evento ha un argomento “SimpleChanges” che contiene i parametri di Input modificati ed i relativi valori (correnti e vecchi).

Con la sintassi base per la dichiarazione di un parametro di Input ovvero quella che antepone il decoratore @Input() davanti al nome di una variabile, posso lanciare un operazione su dati solo nell’evento ngOnInit. Ora, visto che l’evento ngOnInit viene eseguito una sola volta all’atto della creazione di un componente, in seguito se un parametro di Input cambia non siamo in grado di rilanciare un operazione sui dati. L’evento ngOnChanges(changes: SimpleChanges) può risultare utile in un contesto simile, perché notifica tutte le volte che un parametro di Input viene modificato, permettendoci di rilanciare eventuali operazioni sui dati.

Nel caso abbiamo la necessità di rilanciare un operazione sui dati tutte le volte che un parametro di Input viene modificato, ma non vogliamo utilizzare l’evento ngOnChanges(changes: SimpleChanges), abbiamo un’altra possibilità. Dichiarare il parametro di Input con getter e setter.

In questo modo quando il parametro di Input viene modificato, viene automaticamente invocato il metodo this.updatePeriodTypes().

Una cosa importante che dobbiamo tenere in considerazione è questa. Abbiamo detto che Angular notifica tramite l’evento ngOnChanges(changes: SimpleChanges) quando un parametro di Input viene modificato. Senza entrare troppo nel dettaglio, questo avviene confrontando i vecchi valori con i nuovi, e nel caso risultano diversi scatta la notifica. Per questo motivo dobbiamo tenere in considerazione se stiamo operando con tipi valore o tipi referenza (un’oggetto). Se stiamo lavorando con un oggetto e modifichiamo il valore di una sua proprietà, Angular non si accorge della modifica perché la referenza non è cambiata, per questo motivo l’evento ngOnChanges(changes: SimpleChanges) non scatterà.

A questo punto potremmo continuare il discorso parlando di “Immutabilità degli oggetti” e di “OnPush Change Detection Strategy” ma non fa parte di quest’articolo.

Subject

Una delle regole fondamentali quando si parla di architetture software è che ci sia un debole accoppiamento tra le parti, ovvero che non ci creino situazioni in cui una parte dipende dall’altra a causa ad una referenza tipizzata. Con i decoratori di @Input / @Output possiamo mettere in comunicazione 2 componenti nel caso ci sia una relazione padre e figlio, senza incorrere in questo tipo di problemi. Nel caso invece tra 2 o più componenti non ci sia una relazione padre e figlio dobbiamo usare altre tecniche per raggiungere lo scopo. In Angular ci viene in aiuto il Subject che è un tipo speciale di Observable (infatti un Subject è al tempo stesso Observer e Observable). Per cui se creiamo un servizio singleton che incapsuli un Subject, permettiamo a n. componenti di registrarsi e rimanere in attesa di notifiche, che possono provenire da altri componenti. In questo modo l’unica dipendenza che ha un componente è quella del servizio. Sotto un esempio.

1) Introduzione ad Angular / Sommario

2) Angular Component Communication (Data Binding) – parte 1

3) Angular Component Communication (decoratori @Input, @Output) – parte 2

4) Cosa sono le Template Reference Variable e i decoratori @ViewChild @ViewChildren @ContentChild @ContentChildren in Angular

5) Cosa sono le “projection” in Angular (ng-content ContentChild ContentChildren)

6) Come manipolare il DOM da un applicazione Angular

Se volete contattarmi il mio profilo Linkedin è il seguente:
Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Eseguire e debuggare un' applicazione ASP.NET Core in Visual Studio utilizzando WSL (windows subsystem for linux)

Stefano Marchisio (sviluppatore freelance) — Sat, 30 Jan 2021 11:19:55 +0000

Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Introduzione

Il “sottosistema Windows per Linux” (o wsl) consente agli sviluppatori di eseguire un ambiente Linux all’interno di Windows, questo ambiente include la maggior parte delle applicazioni e degli strumenti da riga di comando presenti in Linux, il tutto senza il sovraccarico di una macchina virtuale tradizionale o di una configurazione di doppio avvio.

Ciò risulterà utile (non in produzione) nel momento in cui vogliamo effettuare il debug di un applicazione ASP.NET Core in ambiente Linux. Seppur con ASP.NET Core sia possibile creare applicazioni multipiattaforma (Windows, Linux, Mec), se un’applicazione è stata sviluppata in ambiente Windows quando viene pubblicata in ambiente Linux possono sorgere dei problemi (per esempio a causa di come sono scritti i percorsi dei file). In questo modo sarà possibile lanciare l’applicazione ed effettuare il debug all’interno di Visual Studio (nelle cartelle di progetto in Windows), utilizzando un runtime di una macchina Linux a tutti gli effetti, per riscontrare e correggere eventuali problemi.

Esistono 2 versioni di WSL (windows subsystem for linux), più precisamente WSL1 e WSL2. In WSL1 non è presente un kernel linux, l’applicazione viene eseguita tramite una traslazione tra la “distribuzione linux” ed il “kernel windows”. Con l’avvento di WSL2 Microsoft abbandona l'emulazione delle API e integra una copia dell'interno kernel Linux all’interno di Windows. Il kernel è stato prelevato dal sito ufficiale (kernel.org), ottimizzato allo scopo e ricompilato; viene poi eseguito all'interno di una macchina virtuale light invisibile all'utente.

Windows subsystem for linux è presente di default in Windows 10 (anche se non attivato), in quest’articolo vedremo come attivarlo e come scaricare una distribuzione Linux dallo store di Windows 10. Una volta che avremo poi un sottosistema Linux funzionante, vedremo come fare il deploy di un applicazione ASP.NET Core e come fare l’ ”attach” del “debugger” per poterla debuggare.

Attivazione del Windows subsystem for linux

Per prima cosa dobbiamo andare attraverso il pannello di controllo in istallazione programmi e cliccare su “Turn windows features on or off”. A questo punto verrà visualizzato un popup con le varie features che possono essere attivate, se non sono già state selezionate dobbiamo selezionare: “Virtual Machine Platform” e “Windows Subsystem for Linux”.

Dopo aver riavviato il pc Windows avrà installato ciò che ci serve, o meglio avrà predisposto la macchina installando il Kernel Linux anche se non sarà ancora presente una distribuzione Linux reale. Per installare una distribuzione Linux reale dobbiamo invece andare sul Windows Store e scegliere la distribuzione che desideriamo installare tra quelle disponibili.

Installazione di una distribuzione Linux

Dopo che Windows ha finito di scaricare la distribuzione selezionata dobbiamo lanciarla come si farebbe con qualsiasi altra applicazione. La prima volta si aprirà una finestra console e verrà chiesto di attendere uno o due minuti affinché i file vengano decompressi e archiviati sul pc (i lanci futuri dovrebbero richiedere meno di un secondo), verrà inoltre chiesto di inserire uno “username” ed una “password”.

A questo punto la distribuzione Linux da noi scelta è stata installata sul pc. Infatti se apriamo il menu start di Windows la vedremo insieme agli altri programmi, analogamente se clicchiamo si aprirà una finestra console con un terminale Linux. Importante, potrebbe comparire la scritta “Access is denied”, per ovviare a questo problema dobbiamo lanciare la console come amministratore.

Come si può vedere dall’immagine sovrastante una volta entrati nel sottosistema Linux ci troviamo nella directory di lavoro assegnata al nostro utente, sarà quindi possibile eseguire qualsiasi comando Linux.

Conosciamo il commando WSL.EXE

Nel momento in cui è stato attivato/installato “windows subsystem for linux” è stato aggiunto al prompt dei comandi un nuovo comando: wsl.exe. Questo comando ci permette di gestire le varie distribuzioni Linux presenti sulla nostra macchina ed in particolar modo di: 1) visualizzare le distribuzioni linux installate (può essere presente anche più di una distribuzione). 2) Lanciare una distribuzione. 3) Impostare wsl1 o wsl2 come formato predefinito quando si installa una nuova distribuzione 4) Convertire una distribuzione da un formato all’altro: wsl1 => wsl2 o wsl2 => wsl1 5) Molto altro ancora

Come si può vedere dall’immagine sovrastante sul sistema era già presente la distribuzione 20.04 di Ubuntu, nell’esempio abbiamo voluto installare anche la distribuzione 18.04 di Ubuntu. Come si può vedere la distribuzione appena installata utilizza il formato wsl1, pertanto dobbiamo convertirla al formato wsl2. Questo può essere fatto attraverso il comando “wsl –set-default Ubuntu-18.04 2”.

Adesso entrambe le distribuzioni utilizzano il formato wsl2. E’ possibile lanciare una distribuzione oltre che dal menu start di Windows anche attraverso il comando wsl, infatti i se digitiamo il comando “wsl -d Ubuntu-18.04” verrà aperta un finestra di terminale con la distribuzione desiderata. Per verificare che la versione sia quella corretta possiamo digitare il comando “lsb_release -a”. Maggiari informazioni sul comando wsl le potete trovare nella guida in linea di wsl.

Interoperabilità tra il file system di Windows e quello di Linux

Giunti a questo punto ci ritroviamo più sistemi operativi affiancati, in particolar modo abbiamo Windows che funge da host e una o più distribuzioni Linux che girano su macchine virtuali light. Per rendere più agevole il lavoro dello sviluppatore, da ognuno dei sistemi operativi è possibile accedere agevolmente al file system degli altri sistemi operativi.

1) Dall’interno di Windows è possibile accedere al file system delle varie distribuzioni Linux attraverso la risorsa di rete \wsl$.

2) Analogamente ogni distribuzione Linux monta il file system della macchina Windows sul seguente percorso “/mnt/”.

In questo modo, in seguito sarà facilmente possibile posizionarsi nella directory di lavoro di un progetto Visual Studio (in Windows) dall’interno di un ambiente Linux, per poter poi lanciare la soluzione o avviare il debug in ambiente Linux.

Come mostra l’immagine sovrastante, dall’interno di un ambiante Linux ci siamo posizionati in un progetto Visual Studio (in Windows) contenuto nel drive “Z”.

Dall’interno di un ambiente Linux è anche possibile digitando il comando “explorer.exe .” aprire esplora risorse in Windows, mostrando il contenuto di una directory dell’ambiente Linux. Infatti l’interprete dei comandi Linux, prova a lanciare in Windows ogni file che ha come suffisso “.exe”

Perché usare Sottosistema Windows per Linux anziché Linux in una macchina virtuale?

Sottosistema Windows per Linux richiede un minor numero di risorse (CPU, memoria e file system) rispetto a una macchina virtuale completa. Consente di eseguire applicazioni e strumenti da riga di comando di Linux insieme alle applicazioni desktop Windows e di accedere ai rispettivi file system.

NOTA IMPORTANTE: una delle principali limitazioni di Sottosistema Windows per Linux è la mancanza di supporto per la modifica diretta di file nel file system delle distribuzioni Linux tramite applicazioni o strumenti di Windows. Vedi: Do not change Linux files using Windows apps and tools (non modificare i file linux usando app e strumenti di windows).

Spostiamo la distribuzione appena installata in un'altra cartella

Di default le varie distribuzioni linux installate vengono messe all’interno di “C:”, questo può essere un problema se abbiamo un SSD con poco spazio, per questo motivo dobbiamo trovare un modo per poterle spostare in altra unita.

Questo può essere fatto tramite utility “LxRunOffline” che viene lanciata all’interno della power shell di Windows. Per installare “LxRunOffline” dobbiamo aver prima installato il package manager “Chocolate”.

Come si può vedere dall’immagine sovrastante la distribuzione verrà spostata nella cartella: “Z:\zzz-linux\Ubuntu-18.04”.

Installiamo l’SDK o il RUNTIME di ASP.NET Core nella distribuzione Linux

Prima di continuare di continuare dobbiamo però installare l’SDK o il RUNTIME di ASP.NET Core nella distribuzione Linux. Per far ciò si utilizzano i package manager presenti in Linux.

L'installazione con APT può essere fatta con pochi comandi, però prima di installare dotnet si devono eseguire i seguenti comandi per aggiungere la chiave di firma del pacchetto Microsoft all'elenco di chiavi attendibili e aggiungere il repository del pacchetto. Aprire quindi un terminale Linux e digitare.

wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb

sudo dpkg -i packages-microsoft-prod.deb

A questo punto è possibile installare dotnet scegliendo se installare anche SDK o solo il RUNTIME, nel caso si decide di installare l’SDK non è più necessario installare il RUNTIME.

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \

sudo apt-get update && \

sudo apt-get install -y dotnet-sdk-5.0

oppure

sudo apt-get update; \

sudo apt-get install -y apt-transport-https && \

sudo apt-get update && \

sudo apt-get install -y aspnetcore-runtime-5.0

Maggiori informazioni è possibile trovarle qui

Una volta che abbiamo installato SDK o il RUNTIME possiamo provare ad eseguire la nostra applicazione all’interno dell’ambiente Linux, ma per far ciò dobbiamo prima fare il deploy all’interno di un folder di prova.

La directory dove è stata pubblicata l’applicazione è la seguente.

Z:\zzz-linux\Projects\WebApplication1\WebApplication1\bin\Debug\net5.0\publish

Apriamo ora un terminale Linux e tramite il comando “cd” ed entriamo nella directory dove è stata pubblicata l’applicazione.

cd /mnt/z/zzz-linux/Projects/WebApplication1/WebApplication1/bin/Debug/net5.0/publish

A questo punto possiamo lanciare l’applicazione tramite il commando “dotnet”.

dotnet WebApplication1.dll

Come si può vedere dall’immagine sovrastante il server “Kestrel” è partito e ci segnala che l’applicazione è ora visibile ai seguenti indirizzi: “http://localhost:5000” e “https://localhost:5001” (da tener presente che la console è in ambiente Linux). Se ora apriamo il browser all’interno di Windows ed inseriamo uno dei 2 indirizzi, vedremo la nostra applicazione.

Abilitiamo il protocollo SSH ed installiamo il debugger remoto di dotnet

Fino ad ora ci siamo limitati a lanciare un applicazione in ambiente Linux da un browser in Windows. Ma prima di poter effettuare il debug dobbiamo fare ancora un paio di cose.

Essendo Visual Studio e l’ambiente Linux che esegue l’applicazione su 2 sistemi operativi diversi, siamo obbligati a lanciare una sessione di debug remoto. Per questo motivo dobbiamo abilitare protocollo SSH e poi installare il debugger remoto di dotnet all’interno di Linux.

I default è presente un server SSH all’interno della distribuzione Linux, ma a volte capita che nel momento in cui viene lanciato solleva un errore. Per questo motivo è bene disinstallarlo per poi installarlo nuovamente.

sudo apt-get remove openssh-server

sudo apt-get install openssh-server

Una volta reinstallato il server SSH dobbiamo andare a impostare i parametri di configurazione “PasswordAuthentication yes” e “AllowUsers ” contenuti nel file “/etc/ssh/sshd_config”. Infatti di default la password authentication è disabilitata e non sono presenti utenti nella lista degli utenti abilitati. Per editare il file “/etc/ssh/sshd_config” possiamo se non ancora presente installare “nano”, un semplice e funzionale editor di testo.

sudo apt-get install nano

sudo nano /etc/ssh/sshd_config

PasswordAuthentication yes

AllowUsers

Una volta terminata la configurazione del servizio SSH riavviamo il server.

sudo service ssh --full-restart

Installiamo ora l’ unzip e il debug di dotnet.

sudo apt-get install unzip

curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg

Tramite “curl” scarichiamo lo script “getvsdbgsh” che una volta lanciato provvederà a completare l’istallazione e la configurazione del debugger.

Se tutto à andato per il verso giusto, siamo ora in grado di lanciare da Visual Studio una sessione di debug di un applicazione che viene eseguita in ambiente Linux. Prima di lanciare la sessione di debug recuperiamo però l’indirizzo ip dell’ambiente Linux.

Nel momento in cui clicchiamo su “OK” partirà il debug di Visual Studio, se inseriamo un break-point sul metodo “Index” nel momento in cui effettuiamo il refresh della pagina il debug si arresterà al punto selezionato.

Conclusioni

Giunti a questo punto abbiamo visto come è possibile lanciare una sessione di debug da Visual Studio di un applicazione eseguita in un ambiente Linux.

Links

Windows Subsystem for Linux Installation Guide for Windows 10

Install .NET on Linux

Install the .NET SDK or the .NET Runtime on Ubuntu

Debugging .NET Core on Unix over SSH

Move/Install WSl distro from C drive to another drive

Se volete contattarmi il mio profilo Linkedin è il seguente:
Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Differenze tra providers vs viewProviders in Angular (e tree shaking)

Stefano Marchisio (sviluppatore freelance) — Sun, 29 Nov 2020 15:38:45 +0000

Come modificare il meccanismo di dependency injection presente in Angular.

Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

Introduzione

L’obiettivo del presente articolo e spiegare la differenza tra l’injectors “providers” e l’injectors “viewProviders”. Anche se non è trattato pienamente nel presente articolo, facciamo prima un piccolo recall del meccanismo di dependency injection presente in Angular.

In Angular (come in altri framework) è presente una funzionalità per creare e iniettare un oggetto nel costruttore di una classe. L’oggetto iniettato potrà poi essere di 2 tipi: 1) Singleton ovvero verrà creata un'unica istanza condivisa che verrà iniettata tutte le volte che viene richiesta 2) Verrà iniettata una nuova istanza tutte le volte che viene richiesta.

Decidere di attivare una modalità piuttosto che l’altra dipende dove viene registrato il servizio!

1) Se un servizio viene registrato all’interno di un modulo tramite l’array providers avremo un servizio singleton (dalla versione di Angula 6 abbiamo anche l’attributo providedIn del decoratore @Injectable, vedi sotto).

2) Se un servizio viene registrato all’interno di un componente tramite l’array providers avremo un nuovo servizio che verrà creato tutte le volte che un componente viene istanziato, tale servizio sarà poi visibile sia dal componente che lo ha registrato e sia dagli eventuali figli presenti nel componente che ne fanno richiesta.

Entrando nel dettaglio, quando all’interno del costruttore di un componente viene richiesto un servizio, il motore di dependency injection presente in Angular per prima cosa guarda se nel componente è stato registrato un servizio, in caso contrario risale l’albero dei componenti per guardare nei componenti di livello superiore, se giunto al nodo radice non ha trovato niente guarda allora nel modulo. Ciò implica che in Angular esistono 2 tipi di injector: root-injector e child-injector.

Fin qui nulla di strano, e per maggiori informazioni sulla dependency injection si rimanda alla documentazione ufficiale.

Arriviamo ora allo scopo del presente articolo, la cosa che forse molti non conoscono è che all’interno di un componente è possibile registrare un servizio oltre che con l’array “providers” anche con l’array “viewProviders”. Infatti nel decoratore “@Component” usato per definire un componente, oltre alle proprietà base: selector, templateUrl, styleUrls; troviamo le proprietà: providers e viewProviders (che servono appunto per registrare un servizio).

Non si riscontrano differenze tra “providers” e “viewProviders” finchè all’interno del template HTML non è presente un tag <ng-content>; ovvero esiste del contenuto proiettato. Ciò vuol dire che in un componente “Padre” i figli vengono iniettati nel seguente modo: <parent><child></child></parent>.

In questo caso (se esiste del contenuto proiettato) se un componente “child” richiede un servizio (che è registrato nel “parent”) il motore di dependency injection presente in Angular NON fornirà il servizio come avverrebbe di default, ma va subito in cima al component tree. Questo avviene per prevenire che librerie di 3 parti possano usare dei nostri servizi. Vediamo ora 3 brevi esempi.

I 2 templete HTML sovrastanti sono utilizzati nell’esempio 1 e nell’esempio 2. Come si può vedere vengono definiti 2 componenti “parent” affiancati, all’interno di ogni componente parent è poi presente un componte “child”.

1) Il servizio è registrato solo all’interno del modulo

In questo primo esempio sono presenti 2 componenti “parent” affiancati, sia il componente “parent” che il componente “child” (definito all’interno del componente parent) richiedono lo stesso servizio. Essendo il servizio registrato nel modulo otterranno tutti la stessa istanza (parent e child). Per questo motivo qualsiasi cosa che venga digitata in una delle 2 textbox del componente “parent” verrà replicata anche nell’altra textbox, così come nella lables dei controlli “child”.

2) Il servizio è registrato all’interno del componente parent tramite “providers”

In questo secondo esempio sono presenti 2 componenti “parent” affiancati, sia il componente “parent” che il componente “child” (definito all’interno del componente parent) richiedono lo stesso servizio. Essendo il servizio registrato nel componente “parent” verranno create 2 istanze diverse per ciascun componente, i componenti “child” otterranno poi l’istanza del componente “parent” corrispondente. Per questo motivo le 2 textbox saranno disgiunte, quello che viene digitato in una textbox non verrà replicato anche nell’altra textbox, verrà solo replicato nel componente “child” corrispondente.

3) Il servizio è registrato all’interno del componente parent tramite “viewProviders”

Quello visto fino ad ora è il funzionamento standard del motore di dependency injection presente in Angular. Vedremo ora che in presenza di contenuto proiettato, se un servizio è registrato tramite “viewProviders”, le cose cambiano.

Sotto si può vedere il template HTML del componente contenitore

Sotto si può vedere il template HTML del componente “parent”

Come si può vedere nei template HTML sovrastanti all’interno del componente contenitore sono presenti 2 componenti “parent” affiancati: <parentc><child></child></parentc>. Il componente “child” in questo caso viene proiettato a differenza dei 2 esempi precedenti in cui era dichiarato nel componente “parent” corrispondente. Nel componente “parent” troviamo solo il tag <ng-content>. Cosa importante, nel componente “parent” il servizio è registrato attaverso “viewProviders”.

In questo terzo esempio sono presenti 2 componenti “parent” affiancati, sia il componente “parent” che il componente “child” richiedono lo stesso servizio, in questo caso però il componente “child” viene proiettato. Essendo il servizio registrato nel componente “parent” verranno create 2 istanze diverse per ciascun componente. Per questo motivo le 2 textbox saranno disgiunte, quello che viene digitato in una textbox non verrà replicato anche nell’altra textbox. A differenza degli altri 2 esempi, ciò che viene digitato in una textbox NON verrà replicato nel componente “child” corrispondente, questo perché il componente “child” non otterrà l’istanza del servizio dal componente “parent” perché registrato con “viewProviders”. Questo avviene per prevenire che librerie di 3 parti possano usare dei nostri servizi.

Servizi tree-shakable

Il tree shaking è l’operazione che implica la rimozione del codice non utilizzato all'interno di un'applicazione Angular in modo che non sia presente nel bundle filale.

Con Angular Ivy il nuovo set di istruzioni è stato progettato per raggiungere gli obiettivi sopra menzionati. Infatti è stato progettato per essere completamente tree-shakeable. Ciò significa che se non viene utilizzata una particolare funzione di Angular, le istruzioni corrispondenti a quella funzione non saranno inserite nel bundle finale, al contrario il vecchio motore di render ViewEngine non era completamente tree-shakeable. Per quanto riguarda i servizi, un servizio è tree-shakable se non viene incluso nel bundle finale se non è mai stato fatto riferimento ad esso nell’applicazione.

Detto questo, i servizi definiti nell’array provider all’interno di un modulo (non di componente) non sono tree-shakable. Ma se si registra un provider direttamente all'interno del decoratore @Injectable() utilizzando l'attributo providedIn, se non viene utilizzato nell'applicazione non verrà inserito nel bundle.

Questa nuova modalità è stata introdotta a partire da Angular 6, ma tutto ciò che è stato detto poco sopra in merito a “providers” e “viewProviders” è sempre valido.

Conclusioni

Anche se poco utilizzato abbiamo visto che esiste anche l’array “viewProviders”, che potrà venirci in aiuto per modificare il meccanismo di default del motore di dependency injection presente in Angular. Pur non essendo oggetto del presente articolo esistono anche altri metodi per cambiare tale comportamento. Infatti se si fa precedere il nome del servizio che deve essere iniettato nel costruttore con un decoratore di parametro: @Optional, @Self, @SkipSelf, @Inject, @host, etc; il risultato sarà un comportamento diverso.

Se volete contattarmi il mio profilo Linkedin è il seguente:
Stefano Marchisio - sviluppatore freelance: angular | asp.net core mvc c#

DEV Community: Stefano Marchisio (sviluppatore freelance)

Introduzione ad Angular

In questo Angular tutorial verranno trattati: Data Binding | decoratori @Input, @Output | decoratori @ViewChild, @ViewChildren, @ContentChild, @ContentChildren | content projection | manipolazione del DOM

Come manipolare il DOM da un applicazione Angular

Quest'articolo spiega come manipolare il DOM in Angular attraverso le “Directive attributo” e le “Directive strutturali” piuttosto che lavorare a basso livello usando “Renderer2” e “ViewContainer” (ElementRef, TemplateRef, ViewContainerRef)

Introduzione

Come facciamo

Direttive “Attribute directive” e “Structural directive”

“Renderer2” e “ViewContainer”

“Renderer2”

“ViewContainer”

ngTemplateOutlet e NgComponentOutlet

Conclusioni

Angular Component Communication (Data Binding) – parte 1

Quest'articolo mostra i 4 tipi di databinding presenti in Angular: Iterpolation, Property binding, Event binding, TwoWay binding

Data Binding

Interpolation data binding

Property data binding

Event data binding

TwoWay data binding

Cosa sono le “projection” in Angular (ng-content ContentChild ContentChildren)

Quest'articolo spiega il concetto di projection in Angular, l'uso del tag ng-content e come recuperare il contenuto proiettato attraverso i decoratori: @ContentChild @ContentChildren

PageComponent

TabsComponent

TabComponent

Cosa sono le Template Reference Variable e i decoratori @ViewChild @ViewChildren @ContentChild @ContentChildren in Angular

Quest'articolo mostra l'uso delle “Template Reference Variable” e come fare delle query DOM attraverso: @ViewChild @ViewChildren @ContentChild @ContentChildren per recuperare referenze

Template Reference Variable

Sotto un primo esempio

Sotto un secondo esempio

Angular Component Communication (decoratori @Input, @Output) – parte 2

Quest'articolo mostra l'uso dei decoratori di @Input, @Output per passare dati piuttosto che ricevere eventi.

Parent Component

Child Component

Subject

Eseguire e debuggare un'​ applicazione ASP.NET Core in Visual Studio utilizzando WSL (windows subsystem for linux)

Introduzione

Attivazione del Windows subsystem for linux

Installazione di una distribuzione Linux

Conosciamo il commando WSL.EXE

Interoperabilità tra il file system di Windows e quello di Linux

Spostiamo la distribuzione appena installata in un'altra cartella

Installiamo l’SDK o il RUNTIME di ASP.NET Core nella distribuzione Linux

Abilitiamo il protocollo SSH ed installiamo il debugger remoto di dotnet

Conclusioni

Links

Differenze tra providers vs viewProviders in Angular (e tree shaking)

Come modificare il meccanismo di dependency injection presente in Angular.

Introduzione

1) Il servizio è registrato solo all’interno del modulo

2) Il servizio è registrato all’interno del componente parent tramite “providers”

3) Il servizio è registrato all’interno del componente parent tramite “viewProviders”

Servizi tree-shakable

Conclusioni

Eseguire e debuggare un' applicazione ASP.NET Core in Visual Studio utilizzando WSL (windows subsystem for linux)