Ci siamo lasciati con questo esempio di codice che stiamo vedendo a schermo in cui utilizziamo la callback per eseguire una determinata azione dopo che un numero indefinito di secondi è passato e questo numero indefinito di secondi dicevamo, potrebbe essere il tempo di connessione un database.

Il tempo che l'utente immette qualcosa con la tastiera o determinato evento volge al termine.

Le colpe sono estremamente comode, ma andando avanti sono state introdotte delle nuove formule per andare a lavorare con questi queste funzioni a sincrone.

Ed è qui che vorrei introdurre le promise promise sono arrivano da una classe chiamata promise che appunto permette di utilizzare dei costrutti leggermente diversi.

Lasciatemi spiegare perché diventa estremamente simpatico, per cui in questo momento facciamo così lasciamo il nostro set time out e lasciamo col database, ma a questo punto facciamo ritorno new promises con resolve.

A questo punto muoviamo tutto il nostro set time out all'interno della callback di Promise e al posto di chiamare il call back chiamiamo risolve callback non ci serve più.

A questo punto magari chiudo qua.

A questo punto quello che faremo è col database e al posto di passare una callback possiamo usare due nuovi costrutti, ben, anzi tre.

Adesso però ne vediamo uno per primo.

Data è ben accetta a sua volta una callback per cui data console log data semplicemente per ora allunghiamo database.

Vediamo subito se funziona.

Aspettiamo tre secondi.

Perfetto.

Riproviamo.

Questa volta dovremo aspettare cinque secondi e continua a funzionare.

Ancora tre secondi E come vedete, ogni volta andiamo.

Ogni volta che passa questo numero di secondi chiamiamo, risolve che gli passa questo ray di oggetti per cui non dobbiamo piu' utilizzare una callback.

Aggiungiamo un livello di complessità.

Facciamo reject, per cui Eav facciamo un esempio random di lei è minore di tre Bridget error too quick.

Una cosa che spero che non succeda mai.

Facciamolo solo come esempio.

Questo genererà un errore.

E come facciamo a gestire la possibilità che possa esserci un errore? Diventa estremamente semplice.

Catch, quindi catch.

Prendiamo l'errore error Consob log error.

Poi, naturalmente, lo possiamo gestire come preferiamo.

Quindi se il di lei è minore di tre di tre secondi, in questo caso ci darà un errore.

Vediamo di lei quattro secondi, quindi semplicemente bloccheremo il risultato di lei.

Quattro secondi ancora.

Vediamo quanto ci mettiamo a raggiungere un minore di tre.

Ok, tre secondi.

Ci serve un due uno uno, altrimenti lo forziamo.

Ok, due secondi.

Errore tu qui.

Perfetto.

Ora un'ultima, cosa che potrebbe servirci è indipendentemente dal fatto che sia andato tutto a buon fine oppure no.

Potremmo voler eseguire un'ultima azione, ad esempio finali.

Quindi, indipendentemente dal fatto che possa esserci un errore oppure il risultato che ci stiamo aspettando.

Un'ultima callback un solo luogo in questo caso, diciamo col finisce Vediamo ancora una volta aspettiamo un secondo errore, Tuck e finali col finisce Naturalmente qua siamo estremamente semplici, rendendo le cose estremamente semplici.

È però ci fa capire quanto possa essere piu' efficiente questo metodo di lavoro per cui abbiamo una operazione asincrona.

Poi, quando i dati arrivano, facciamo questa questa azione.

Quando abbiamo un errore, gestiamo l'errore in quest'altro modo, indipendentemente da tutto.

Se ne abbiamo bisogno, possiamo eseguire quest'ultima funzione.

Non è tutto qui ciò che le promesse hanno da darci perché esiste un altro costrutto chiamato Async await async await è estremamente comodo e si utilizza in questo modo.

Creiamo una funzione main, ad esempio, e prima di function, diciamo async.

Quindi diciamo che questa funzione è asincrona.

A questo punto consta data uguale a White col database.

E una volta che abbiamo i dati, solo log beta.

Cosa succede se c' è un errore, però andiamo a vedere.

Ops, Giustamente.

Devo chiamarlo Main.

Cinque secondi di lei.

Nessun errore.

Eccoli qua.

Quindi a questo punto aspettiamo cinque secondi, poi lo chiamo nella console.

Ancora cinque secondi.

Magari lo stop.

Vediamo se riusciamo a prendere.

È incredibile.

Ok, due secondi.

Ops.

Un errore che non ci aspettavamo.

Ok, vedete, questo ci sta dicendo chiaramente Guarda che hai una promessa da qualche parte dove L'errore non viene preso in considerazione.

Attento, perché questa cosa spacca il browser lo spaccano di Insomma, può creare dei problemi per cui per gestirla, gestiamo come si gestisce qualunque altro errore in John Street Drive, Keke.

Quindi se abbiamo i dati consolò Gates, Se abbiamo l'errore consolò ops without an error E poi con solo blog errori.

E come prima possiamo accusare finali senza le parentesi finali.

Console blog finisce.

Andiamo a vedere cosa succede.

Aspettiamo tre secondi.

Ok, abbiamo tutti i dati un secondo, Bob Stuck.

Erro Quindi il nostro errore e poi finisce.

Per cui, come vedete Await ci permette.

Magari togliamo un po' di rumore.

Adesso rendiamo le cose un po' più semplici await ci permette di ragionare in termini sincroni o che per noi possono sembrare sincroni anche quando le funzioni effettivamente sono completamente asincroni, per cui diventa estremamente comodo.

Non tutte le volte abbiamo bisogno, naturalmente, di questo livello di complessità e non ci saranno dei casi in cui questo potrebbe anche essere una vera killer, ma ancora una volta non c' è altra altro modo di imparare a distinguere queste casistiche se non fare tanto, tanto tanto esercizio.