Change Detection

Per svolgere il suo lavoro è stato trasformato in un mostro, ma dentro di lui vive ancora una parte sana

Change Detection

È il meccanismo per il rilevamento delle modifiche.
Consiste nell'eseguire controlli tra due stati,
lo stato corrente ed il nuovo stato

Come scopo finale ha il compito di notificare al browser
eventuali modifiche del DOM, necessarie per aggiornare la vista quando i dati sono cambiati

Change Detection

Angular esegue il codice applicativo (a) durante il rilevamento modifiche (b) e notifica al browser eventuali aggiornamenti DOM necessari. Il browser aggiorna la vista (c)

Change Detection

Angular divide l'aggiornamento del modello dell'applicazione e riflette lo stato del modello nella vista in due fasi distinte:

• Lo sviluppatore è responsabile dell'aggiornamento dello stato dell'applicazione
• Angular, mediante change detection, è responsabile della proiezione dello stato nella vista

Change Detection

Ogni applicazione è un insieme di componenti correlati insieme (da Input ed Output) per essere in grado di propagare dati (stato dell'applicazione)

La tua applicazione è strutturata in ciò che chiamiamo un albero di componenti

Change Detection

Unidirectional Data Flow

Change Detection
Unidirectional Data Flow

• Lo sviluppatore apporta modifiche al modello (stato)
• Change Detection interviene per propagare le modifiche
• Change Detection passa attraverso tutti i componenti nell'albero dei componenti (dall'alto verso il basso) per verificare se esistono cambiamenti
• Se è il caso, aggiorna il componente
• Esegue l'update della view del componente (DOM)

Change Detection
Unidirectional Data Flow

Come possiamo riportarlo sulla retta via?

...che domande...chiamo Batman!

Change Detection
Unidirectional Data Flow

...dopo essermi reso conto che ha da fare mi ridomando...
Come possiamo riportarlo sulla retta via?

• Conoscerlo un po' più a fondo
• Strategie (Default, onPush)
• ChangeDetectorRef
• Best Practice

• Il flusso è sempre dal componente radice verso i nodi più profondi
• Non esiste un ciclo di rilevamento globale. Ogni componente gestisce il proprio rilevamento dei cambiamenti
• Possiamo utilizzare diverse strategie di rilevamento dei cambiamenti per ogni singolo componente

Change Detection
Le Strategie

Per sapere se la vista deve essere aggiornata Angular deve accedere al nuovo valore, confrontarlo con quello vecchio e decidere se la vista deve essere aggiornata

Change Detection
Conoscerlo un po' più a fondo

La Change Detection è eseguita sulla View (ViewRef)

Per Angular, la View è il blocco fondamentale della Application UI

Change Detection
Conoscerlo un po' più a fondo

La View possiede uno stato e memorizza attraverso nodes le referenze al DOM.

Il property checks e l'update del DOM avvengono sotto il cofano per mezzo delle Views

Change Detection
Conoscerlo un po' più a fondo

Le operazioni chiave eseguite dal rilevamento delle modifiche sono le seguenti:

• Update delle child components properties
• Chiamare gli hooks NgDoCheck e NgOnChanges dei child components
• Update del DOM del componente corrente
• Avviare Change Detection per i child components

Change Detection
Conoscerlo un po' più a fondo

La logica portante per la Change Detection risiede sul metodo checkAndUpdateView

Change Detection
Le Strategie - ChangeDetectionStrategy.Default

Ogni volta che qualcosa cambia nella nostra applicazione (come risultato di vari eventi utente, timer, XHR, promise, ecc.), la strategia predefinita esegue un rilevamento delle modifiche su tutti i componenti.

Questa tecnica è chiamata dirty check. Per sapere se la vista deve essere aggiornata, Angular deve accedere al nuovo valore, confrontarlo con quello vecchio e decidere se la vista deve essere aggiornata.

Change Detection
Le Strategie - ChangeDetectionStrategy.Default

Se scegliamo di adottare la strategia di default, è consigliabile seguire alcuni suggerimenti:

• Eseguiamo qualsiasi evento ad alta frequenza fuori dalla Zona
• Evitate il più possibile richieste onerose direttamente collegate alla vista (memoize)
• Eseguiamo Change Detection solo su richiesta

Change Detection
Le Strategie - ChangeDetectionStrategy.onPush

Impostando la strategia di rilevamento su onPush stiamo firmando un contratto con Angular che ci obbliga a lavorare con oggetti immutabili.

Change Detection
Le Strategie - ChangeDetectionStrategy.onPush

Change Detection prenderà il via solo quando:

• Cambiano le referenze @Input
• Un evento è scatenato nel componente o in un child component
• Eseguiamo la CD esplicitamente
  ChangeDetectorRef (detectChanges, markForCheck), ApplicationRef.tick()
• Viene usato il pipe async

Change Detection
Le Strategie - ChangeDetectionStrategy.onPush

Se scegliamo di adottare la strategia onPush, è consigliabile seguire alcuni suggerimenti:

• Creare ed annidare componenti in maniera consapevole
  Usando inoltre componenti più semplici e più riutilizzabili
• Iniettare le proprietà @Input, utilizzando strategie di immutabilità:
  • Usa immutable.js
  • L'implementazione di pattern di state management
  • Object.assing () / {... object}

Change Detection
Le Strategie - ChangeDetectionStrategy.onPush

• Uso degli Observables, che ci avvisano sempre quando arriva una nuova informazione!
  In questi casi potremmo invocare ad esempio markForCheck nel nostro componente nella sottoscrizione o ancora meglio, non sottoscrivere l'osservabile e delegare il tutto direttamente alla AsyncPipe

Change Detection
ChangeDetectorRef

Angular ci offre un servizio chiamato ChangeDetectorRef, che è un riferimento al ChangeDetector iniettabile nel nostro componente

Questo servizio ci facilita la gestione a piacere del rilevatore di modifiche, che è molto utile quando utilizziamo la strategia OnPush o quando eseguiamo il codice al di fuori della zona

Change Detection
ChangeDetectorRef

detach
Quando si richiama questo metodo stiamo rimuovendo il componente (e tutti i suoi figli) dal rilevamento futuro delle modifiche nell'applicazione.
Le sincronizzazioni future tra stati componenti e modelli devono essere eseguite manualmente.

reattach
Quando si richiama questo metodo includiamo di nuovo il componente (e tutti i suoi figli) nelle future rilevazioni delle modifiche dell'applicazione.

Change Detection
ChangeDetectorRef

markForCheck
Quando invochiamo questo metodo ci assicuriamo che il rilevatore di modifiche del componente e di tutti i suoi antenati (fino alla radice del documento) saranno eseguiti nella successiva esecuzione.
Una volta rilevate le modifiche nel componente verrà restituita la strategia di OnPush.

detectChanges
Eseguirà manualmente la rilevazione delle modifiche nel componente
ed in tutti i suoi figli (una sorta di localscope).
Molto utilizzato nei componenti in cui è stato richiamato " detach ", ottenendo così un aggiornamento della vista.

Change Detection
ChangeDetectorRef

checkNoChanges
Controlla se vengono rilevate modifiche (anche ai relativi figli).
Questo metodo è usato in devmode per verificare che il rilevamento delle modifiche in esecuzione non presenti ulteriori modifiche.

Change Detection
Best Practices

Migliorare le prestazioni tende a coinvolgere l'ottimizzazione di tre aspetti principali:

• Esecuzione rapida degli event handlers dell'applicazione
• Riduzione del numero di esecuzioni di callback necessarie per completare un ciclo di Change Detection
• Riduzione del tempo di esecuzione della Change Detection

Change Detection
Best Practice

• Template Methods (precalc/pure pipe)
• Ottimizza o Evita callbacks
• Usa le Pure Pipe
• ngFor (trackBy)
• ngModelOptions="{updateOn:'blur'}"
• Observable Pipeline (distinctUntilChange ad esempio)

Change Detection
Best Practice

• Usa Input Setter al posto di OnChanges
• Cache dove puoi (@memoize su metodi puri)!
• AOT

Change Detection
Best Practice

• Usare onPush
• Rimuovere dalla Change Detection (es. Header/Footer)
• Implementa la tua logica Change Detection

Change Detection
Component Life

• ngOnChanges
• ngOnInit
• ngDoCheck
• ngAfterContentInit
• ngAfterContentChecked
• ngAfterViewInit
• ngAfterViewChecked
• ngOnDestroy

Change Detection
Component Life

• constructor vs ngOnInit
• ngOnChanges vs ngDoCheck
• ngAfterContentInit vs ngAfterViewInit
• ngAfterContentChecked vs ngAfterViewChecked
• ngOnChanges vs ngAfterViewChecked
• ngOnDestroy win! :D

Change Detection
Components - Stateful/Stateless

• Impure Function = Stateful Component
• Pure Function = Stateless Component

Consideriamo pure functions le funzioni che dato uno stesso input ritorneranno sempre uno stesso output (no side-effects)

Change Detection
Components - Stateful/Stateless

• Gestisce eventuali cambiamenti di stato (via services)
• Possono contenere Redux actions (ngrx/store per esempio)
• Gestisce i dati (via services)
• Può ricevere dati via route resolvers
• Possono comunicare con dipendenze esterne
• Hanno child components stateless (ma anche stateful)
• Comunicano con i child componentes stateless via @Input/@Output

Change Detection
Components - Stateful/Stateless

• Nessuna request/fetch di dati
• Ricevono i dati via property binding
• Emettono i dati via event callbacks
• Hanno child components stateless (ma anche stateful)
• Possono contenere local UI state
• Sono un piccolo tassello di un quadro più grande!

Zone.js

Prende il nostro posto ed intercetta tutto ciò che vuole, ma possiamo fermarlo!

Zone.js
Cosa è?

Libreria scritta dal team Angular, ispirata a DART

Un meccanismo di incapsulazione ed intercettazione delle attività asincrone nel browser

Zone.js
Cosa è?

Una zona è un contesto di esecuzione che persiste attraverso attività asincrone
e consente di osservare e controllare l'esecuzione del codice all'interno della zona

Zone.js
A che serve?

• Schedula ed intercetta tutti gli eventi asincroni del browser
• Associa dati alla zona così da essere accessibili a qualsiasi operazione asincrona all'interno della zona stessa
• Utile per determinare i cicli della VM
• Utile Debug, testing e profiling

Zone.js
Come fa ad intercettare gli eventi async?

Zone.js esegue il monkey-patch delle API asincrone e le ridefinisce!

Il monkey-patch è una soluzione per estendere o modificare il software di sistema, senza alterare il codice sorgente (quindi solo sull'instanza in esecuzione)

Durante l'import di zone.js, vengono definite tutte le funzioni/variabili della core zone, richiamando la funzione Zone.__load_patch()

Zone.js
Conosciamolo un po'

In Zone esiste ha la nozione di current zone, che corrisponde all'attuale contesto di esecuzione, al quale si può fare accesso tramite lo static getter Zone.current

Zone.js
Conosciamolo un po'

Ogni zona inoltre ha i getter name e parent

In Zone è inoltre presente il concetto di fork, che consente di creare nuove zone ed impostarne il diretto genitore

Zone.js
Conosciamolo un po'

L'argomento passato al metodo fork è chiamato
zone specification (ZoneSpec)

Zone.js
Come gestire le zone

È possibile eseguire callbacks nelle zone (e quindi variare la current zone) con i seguenti metodi:

• run: invoca una funzione in una determinata zona.
  L'esecuzione di una callback in una zona viene solitamente definita come entrare in una zona
• runGuarded: come run ma con la cattura degli errori
• wrap: produce una nuova funzione che cattura la zona in una closure che eseguirà z.runGuarded(callback) quando invocata

Zone.js
Esempio

Zone.js
Hooks

Zone mantiene tutte le attività in sospeso nella task queue

• onHasTask: notifica quando qualcosa varia nella coda
• onScheduleTask: eseguito ogni volta che viene rilevata un'operazione asincrona come setTimeout
• onInvokeTask: eseguito quando una callback passata a un'operazione asincrona viene eseguita
• onInvoke: notifica ogni volta che si entra in una zona eseguendo run()

Zone.js
Esempio

Zone.js
Quale è la relazione con Angular?

Angular utilizza Zone.js per creare una zona
(via NgZone) che viene utilizzata per eseguire il ciclo di Change Detection.

È un meccanismo molto conveniente per attivare automaticamente la Change Detection chiamando app.tick() invece di farlo manualmente.

Zone.js
Come funziona NgZone?

In Angular, quando effettuiamo una chiamata a

nel nostro main.ts, il modulo viene istanziato, ma prima viene creata un'istanza di NgZone.

application_ref.ts

Zone.js
Come funziona NgZone?

• Nel costruttore di NgZone viene caricato Zone.js che crea una root zone ed un fork chiamato angular.
• Nel fork vengono definiti tutti i callback come facenti parte della zona e saranno richiamati ogni qualvolta un task asincrono verrà scatenato
• Angular sottoscrive questi eventi ed esegue la logica di rilevamento delle modifiche chiamando il metodo tick() dell'ApplicationRef

Zone.js
Come funziona NgZone?

NgZone è quindi il wrapper per dei fork di Zone:

• _inner: corrisponde alla zona angular ed è definita per l'esecuzione all'interno della Angular Zone (NgZone.run())
• _outer: corrisponde al contesto originale prima che sia definita per la Angular Zone (NgZone.runOutsideAngular())

Zone.js
Cosa possiamo fare con NgZone?

Il servizio NgZone ci fornisce gli strumenti per determinare lo stato della zona di Angular ed eseguire codice all'interno o all'esterno di essa!

• runOutsideAngular: Ci consente di eseguire codice al di fuori del contesto di Angular
• run: Ci consente di rientrare nel contesto di Angular

Zone.js
Cosa possiamo fare con NgZone?

• onUnstable: Notifica che del codice è stato inserito ed è in esecuzione nella zona Angular.
• onMicrotaskEmpty: Notifica quando nessun microtasks è accodato per l'esecuzione. Angular sottoscrive questo internamente evento per segnalare che dovrebbe essere eseguito il rilevamento delle modifiche.
• onStable: Notifica quando è stato eseguito l'ultimo onMicroTaskEmpty, il che implica che tutte le attività sono state completate e che il rilevamento delle modifiche è avvenuto
• onError: Notifica la presenza di errori

Zone.js
Posso farne a meno?

Angular può funzionare correttamente senza Zone, per mezzo di una Noop Zone, che disabilita l'esecuzione della Change Detection

Zone.js
Uno stack trace più dettagliato

Zone.js, tenendo traccia di tutte le nostre chiamate asincrone, può fornirci uno stack trace più dettagliato in caso di eccezione

Per farlo è necessario includere il modulo
long-stack-trace-zone nel codice

Ivy

Un nuovo mostro da conoscere
o un nuovo ammaliante alleato?

Ivy
Cos'è?

È il nuovo view engine di Angular
(pipeline e motore di rendering)

Ivy è ancora nelle prime fasi di sviluppo, ma pare che il tutto proceda a gonfie vele!

Miško Hevery e Kara Erickson (♥) hanno mostrato Ivy alla ng-conf 2018

Ivy
Cosa fa il view engine?

Il view engine analizza i componenti (e tutto il resto) e li traduce in normali files HTML e JavaScript, così che il browser possa leggerli e visualizzarli

Ivy è la terza incarnazione del view engine ed arriva dopo il compiler di ng2
ed il renderer2 di ng4 (che è quello che utilizziamo adesso)

Ivy
Perchè un nuovo engine? Perché Ivy è SFS acronimo inventato da me!

Due concetti chiave: Locality e Tree-Shaking

Ivy
Quali sono i vantaggi?

• Build più piccole (parliamo proprio di kb!)
• Tempi di rebuild molto rapidi
• Tempi di sviluppo più rapidi
• Una più semplice e comprensibile pipeline
• Codice prodotto più Human readable

Ivy
Concetto Chiave: Locality

Ivy compila un file alla volta

• Build incrementali e rapidità di compilazione
• Addio all'analisi statica del codice (come su Renderer2)
• Equivalenza tra JIT ed AOT
• Miglior approccio alla Meta-Programmazione (HOC, generazione dinamica dei moduli, componenti, pipes, etc...)

Ivy
Concetto Chiave: Tree-Shaking

Rimuovere parti inutilizzate del codice!

• Genera solo il codice necessario che hai scritto
• Fa in modo che ciò che non stai usando, non venga incluso
  Non porta nella build l'intero codice del framework, ma solo le funzionalità che usi!
  (Non ti serve la Content Projection? Bene, non la builderà!)
• Il tree-shaking verrà applicato a:
  
  
  Template syntax
  Dependency injection
  Content projection
  Structural directives
  Lifecycle hooks
  Pipes
  Queries
  Listeners

Ivy
Tree-Shaking

	import { myCoolFunction } from './other';

	const myCondition = false;
	
	if (myCondition) {
		myCoolFunction();
	}

Ivy
Ivy Pipeline

Google ha riscritto la pipeline di rendering rimuovendo il goffo Angular Interpreter

Ivy
Ivy Pipeline - Angular Interpreter

Attualmente il compilatore produce dei metadati (Template Data) per definire un componente
ed i suoi elementi.
L'Interpreter utilizza questi dati per istanziare componenti ed eseguire il rilevamento delle modifiche.

Ivy
Ivy Pipeline - Angular Interpreter

//My name is {{name}}:
viewDef(0,[
	elementDef(0,null,null,1,'span',...),
	textDef(null,['My name is',...])
]

Ivy
Ivy Pipeline - Incremental DOM (custom)

Per produrre ed aggiornare i componenti e gli elementi vengono utilizzate istruzioni che producono direttamente nodi del DOM
(pussa via metadata!)
Quindi le istruzioni creano il componente, i nodi DOM ed eseguono il rilevamento delle modifiche!
Dall'approccio monolitico dell'interprete ci si è spostati
ad uno atomico delle istruzioni individuali.

Ivy
Ivy Pipeline - Incremental DOM (custom)

//My name is {{name}}:
if (rf & RenderFlags.Create) {
    elementStart(0, 'span');
    text(1);
    elementEnd();

}

// update mode
if (rf & RenderFlags.Update) {
    textBinding(1, interpolation1('My name is', ctx.name));
}

Ivy
Ivy Pipeline

• Ivy è basato su una propria implementazione
  dell'Incremental DOM
  un aggiornamento incrementale di un nodo DOM alla volta!
• I decoratori saranno compilati come proprietà statiche sulle classi (@Injectable >> ngInjectableDef).
  L'unica eccezione è @Component, che richiede la conoscenza dei metadati dal @NgModule che dichiara il componente per generare correttamente il ngComponentDef
• La definizione del componente verrà associata tramite proprietà statica
  Nessun file separato verrà creato durante la compilazione

Ivy Architecture

Ivy
Ivy Pipeline - Incremental DOM (custom) - Component Definition

const componentDefinition = { // ngComponentDef
    type: MyApp,
    selectors: [['my-app']],
>>> template: (rf: RenderFlags, ctx: MyApp) => {
        if (rf & RenderFlags.Create) {
            elementStart(0, 'span');
            elementEnd();
        }
        if (rf & RenderFlags.Update) {
            elementProperty(0, 'name', bind(ctx.name));
        }
    },
    factory: () => new MyApp()
}

Ivy
Ivy Pipeline - Come fa ad essere utile al Tree-Shaking?

Diamo uno sguardo!

Ivy
Ivy Pipeline

Ivy supporta i seguenti decoratori:

• @Component > ngComponentDef
• @Directive > ngDirectiveDef
• @Injectable > ngInjectableDef
• @NgModule > ngNgModuleDef
• @Pipe > ngPipeDef

Internamente questi trasformatori di classe sono chiamati "Compiler".

Ivy
Ivy Pipeline - Change Detection

• L'ordine delle esecuzioni potrebbe essere leggermente diverso e il meccanismo per gli hook del ciclo di vita cambiato
  
  • Sembra che ora Angular controlli prima i child components
    e solo successivamente le embedded views
  • ngOnChanges per mezzo di NgOnChangesFeature dovrebbe wrappare ngDoCheck e valutare se essere eseguito (verrà comunque richiamato prima)
• Le operazioni di controllo sono implementate come istruzioni individuali (funzioni), quindi favoriscono il Tree-Shacking

Ivy
Ivy Pipeline - Change Detection

Internamente l'esecuzione del rilevamento delle modifiche in Ivy viene eseguita chiamando la funzione detectChanges con il componente come argomento, e non con checkAndUpdateView come avviene attualmente.

Ivy
Ivy Pipeline - Change Detection

Ivy
Ivy Pipeline - Change Detection

Ivy
Ivy Pipeline - Alcuni vantaggi nella Dev Experience

Ivy migliorerà la nostra esperienza di sviluppo
rimuovendo gran parte della rendering black box

• I templates faranno parte dello stack trace
  Non dovrai più occuparti dei messaggi di errore criptici quando qualcosa non va e vedrai il numero esatto della linea del template
• Sarai anche in grado di impostare i breakpoint per eseguirne il debug

Ivy
Alcune novità (ma nulla è definitivo)

• Rimossa la dipendenza da platform-browser
• Nessun file NgFactory
• Modalità di Bootstrap semplificata
• Redesign della configurazione e controllo della DevMode
• Nuova feature chiamata Feature
  Feature è un pre-processore per DirectiveDef, che può essere pensato come un "pattern Decorator"
  su misura per DirectiveDef
• Nuova Injectable API
• Nuova template compilation

Ivy
Nuova Modalità di Bootstrap

	import { renderComponent } from '@angular/core'
	import { AppComponent } from './app.component'
	
	renderComponent(AppComponent)

Sarà mantenuto il bootstrap attuale: platformBrowserDynamic().bootstrapModule(AppModule)

Ivy
Quando sarà resa pubblica cosa succederà ai nostri progetti?

Nulla, si dovrebbero solo apprezzare i vantaggi che porterà con se!

...ma tranquilli...ci sarà di sicuro qualcos'altro che romperà i nostri progetti!

Ivy
Come vederlo in azione oggi?

• Installa Bazel (Angular ABC si avvicina sempre più?)
• git clone https://github.com/angular/angular.git
• cd packages/core/test/bundling/todo
• bazel run @yarn//:yarn
• bazel run //packages/core/test/bundling/todo:devserver
  Con :prodserver puoi provare la build di produzione

Oppure date un occhiata qui!

Può essere testato tramite la proprietà enableIvy: true di angularCompilerOptions (tsconfig.json)

Ivy
Quando arriverà?

Google attualmente testa Ivy su oltre 600 prodotti
Senza vergogna alcuna!

Is Angular Ivy ready?