Ciao e complimenti per il video. Per caso hai un video dove spieghi come fare le chiamate asincrone e soprattutto quelle sincrone in javascript? So che quello sincrone ormai non si utilizzano più ma ho avuto a che fare con un progetto che le richiedeva e ho fatto fatica a trovare documentazione i merito. Secondo me sarebbe utile per la community. Ciao
@@codingconmanuel partirei intanto col dire che javascript è un linguaggio orientato agli eventi e single thread non bloccante ed è stato quindi necessario implementare un sistema per eseguire le azioni scaturite dagli eventi e in generale comunque tutte le chiamate asincrone. Il tutto funziona con una parte di memoria dove viene messo il codice che viene eseguito e uno stack o pila che si voglia dire (dico uno ma se non ricordo male ce ne sono due con priorità diverse) dove vengono per l'appunto impilate le funzioni asincrone. L'event loop controlla questa pila e se la parte di memoria di esecuzione del codice è vuota ne prende una e la sposta li per farla eseguire.
@@codingconmanuel successivamente si può fare il classico esempio console.log('start'); setTimeout(()=>console.log('call back'),0); console.log('end'); e chiedere l'output e il motivo dell'ordine delle stampe
@@codingconmanuel dal video sembra che la compilazione serva solo a trasformare il codice sorgente in codice macchina, ma questo non è. Java viene compilato in bytecode ad esempio, typescript addirittura compilato in javascript. Il vantaggio della compilazione prima della distribuzione di un software è quello di avere una prima analisi del software che evita alcuni errori rilevati poi solo in runtime. Comunque capisco che l'argomento era un altro
il font si chiama Dank Mono costa 25 sterline. Lo puoi impostare dalle impostazioni di Visual Studio Code sotto la voce "Editor: Font Family", nel mio caso il valore sarà Dank Mono, Menlo, 'Source Code Pro'. Per maggiori informazioni su come impostare Visual Studio Code puoi guardare il mio video a riguardo ruclips.net/video/SZQp2mRVU0g/видео.html
sull'hoisting manca l'esempio con var secondo me, perchè anche con l'esempio della arrow function vedrete che l'errore cambia a seconda se si usa const o var, invece con una variabile vedrete che con var non darà errore
Hai assolutamente ragione, aggiungere un esempio con var sarebbe stato utile per comprendere meglio l'hoisting! Grazie per il suggerimento. Ecco una spiegazione rapida: Quando usi var: console.log(x); // Risultato: undefined var x = 5; console.log(x); // Risultato: 5 La variabile x dichiarata con var viene, per tradurre alla lettera "issata", il che significa che la sua dichiarazione viene spostata in cima al suo contesto di esecuzione. Tuttavia, solo la dichiarazione viene issata, non l'assegnazione, quindi all'inizio x è undefined. Ora confrontiamolo con let e const: console.log(y); // Risultato: ReferenceError: y is not defined let y = 5; console.log(z); // Risultato: ReferenceError: z is not defined const z = 5; Con let e const, provare ad accedere alle variabili prima della loro dichiarazione genera un errore perché si trovano in una "zona morta temporale" (Temporal Dead Zone) fino alla loro inizializzazione. Questi esempi dimostrano come l'hoisting con var permette l'accesso alle variabili prima che siano inizializzate, restituendo undefined, a differenza di let e const che generano un errore. Ciò detto ricordo che var, nella programmazione JavaScript moderna, viene usato meno spesso, specialmente da quando let e const sono state aggiunte in ES6. Il motivo del declino nell'uso di var si può riassumere in due punti: 1. Scope: var ha uno scope funzionale, il che significa che le variabili dichiarate con var sono accessibili all'interno dell'intera funzione in cui sono dichiarate, indipendentemente dai blocchi di codice (come if o cicli). Al contrario, let e const hanno uno scope di blocco, rendendole accessibili solo all'interno del blocco in cui sono dichiarate. Questo aiuta a prevenire errori dovuti a sovrapposizioni o riutilizzi involontari di variabili. 2. Hoisting: Le variabili dichiarate con var sono soggette a hoisting, il che significa che possono essere usate prima della loro dichiarazione effettiva nel codice, sebbene inizialmente avranno il valore undefined. Questo può portare a confusioni e bug difficili da tracciare. let e const sono anch'esse soggette a hoisting, ma non si può accedere a queste variabili prima della loro dichiarazione effettiva nel codice a causa della cosiddetta "temporal dead zone", riducendo così gli errori. var ha senso usarlo, oggi, solo nel caso di: 1. Compatibilità con vecchi browser 2. Specifiche tecniche particolari In generale, l'uso di let e const è raccomandato per una programmazione più sicura e prevedibile. var è più come un vecchio cimelio di versioni precedenti di JavaScript, e il suo uso è spesso evitato in progetti nuovi o durante la revisione di codice legacy.
perchè per la ricorsione si deve dare importanza al concetto di termine di ricorsione per l'iterazione no? Il concetto di fine ricorsione è ovviamente importante ma trovo della stessa importanza il concetto di fine iterazione
Sia nella ricorsione che nell'iterazione, il concetto di "terminazione" è fondamentale per evitare cicli infiniti e per assicurarsi che il codice faccia esattamente quello che ci aspettiamo in un numero finito di passaggi. La differenza chiave tra ricorsione e iterazione sta nel modo in cui gestiscono la terminazione: 🔁 Ricorsione: Il termine di ricorsione, o "caso base", è essenziale perché impedisce alla funzione di chiamare se stessa all'infinito. Ogni chiamata ricorsiva si avvicina sempre di più al caso base e, una volta raggiunto, la ricorsione si interrompe. La definizione stessa della funzione ricorsiva incorpora questo meccanismo di terminazione. 👀 Iterazione: Nell'iterazione, il controllo di terminazione viene eseguito all'inizio o alla fine di un ciclo (come nei cicli while o for). Qui, devi definire esplicitamente una condizione che determina quando il ciclo deve fermarsi. Questa condizione viene verificata ad ogni iterazione del ciclo. Anche se il principio di avere un "punto di fine" è comune a entrambi i metodi, la loro implementazione e controllo sono molto diversi. Nella ricorsione, il termine è un requisito strutturale critico del processo di chiamata, mentre nell'iterazione è più un controllo di flusso esterno che decide la cessazione del ciclo. Proprio per questo, il caso base nella ricorsione tende ad essere enfatizzato più del controllo di terminazione nell'iterazione, ma come hai giustamente notato, entrambi sono cruciali per il corretto funzionamento del codice.
Grande Manuel !!! interessante Vue + Ts a marzo !!! anche Node + ts .... mamma mia!!!
Grazie mille! Al momento sto pubblicando il corso di TypeScript. Seguilo se ti va
Complimenti Manuel :)
Live molto interessante e formativa
Grazie mille! Mi fa piacere che ti sia piaciuta
Ciao e complimenti per il video. Per caso hai un video dove spieghi come fare le chiamate asincrone e soprattutto quelle sincrone in javascript? So che quello sincrone ormai non si utilizzano più ma ho avuto a che fare con un progetto che le richiedeva e ho fatto fatica a trovare documentazione i merito. Secondo me sarebbe utile per la community. Ciao
Ciao e grazie. Quello che cerchi lo trovi nella lezione 12 del corso di JavaScript ruclips.net/video/1xwPxy9yDTw/видео.html
@@codingconmanuel grazie. Per caso tratterai mai angular sul tuo canale ?
Non ho in programma niente per Angular. Non sono abbastanza confidente da poterlo insegnare
Argomento che chiederei oltre tutti questi che sono molto interessanti è l'event loop
Hai perfettamente ragione. Ho dei colloqui in questi giorni e la domanda è lì tutta bella scintillante: ✨✨ cosa sai dirmi dell'event loop? ✨✨
@@codingconmanuel partirei intanto col dire che javascript è un linguaggio orientato agli eventi e single thread non bloccante ed è stato quindi necessario implementare un sistema per eseguire le azioni scaturite dagli eventi e in generale comunque tutte le chiamate asincrone. Il tutto funziona con una parte di memoria dove viene messo il codice che viene eseguito e uno stack o pila che si voglia dire (dico uno ma se non ricordo male ce ne sono due con priorità diverse) dove vengono per l'appunto impilate le funzioni asincrone. L'event loop controlla questa pila e se la parte di memoria di esecuzione del codice è vuota ne prende una e la sposta li per farla eseguire.
@@codingconmanuel successivamente si può fare il classico esempio
console.log('start');
setTimeout(()=>console.log('call back'),0);
console.log('end');
e chiedere l'output e il motivo dell'ordine delle stampe
Risposta più che valida. Complimenti per la capacità di riassumere un concetto così complesso in poche righe
@@codingconmanuel e poi a sto punto chiederei e con async e await che succede? ma poi ho paura che il loop diventi il colloquio 🤣😂😆😅
Anche sulla compilazione qualcosa da dire avrei
Se vuoi puoi argomentare :)
@@codingconmanuel dal video sembra che la compilazione serva solo a trasformare il codice sorgente in codice macchina, ma questo non è. Java viene compilato in bytecode ad esempio, typescript addirittura compilato in javascript. Il vantaggio della compilazione prima della distribuzione di un software è quello di avere una prima analisi del software che evita alcuni errori rilevati poi solo in runtime. Comunque capisco che l'argomento era un altro
Ciao
Bella live mi ha aiutato molto
Ho una domanda che riguarda l'estetica del tuo visual studio, come fai ad avere questo font?
E anche il tuo theme non è male
@@danielfrimu1996 il tema che uso si chiama CodeSandbox Theme sviluppato da codesandbox.io
il font si chiama Dank Mono costa 25 sterline. Lo puoi impostare dalle impostazioni di Visual Studio Code sotto la voce "Editor: Font Family", nel mio caso il valore sarà Dank Mono, Menlo, 'Source Code Pro'. Per maggiori informazioni su come impostare Visual Studio Code puoi guardare il mio video a riguardo ruclips.net/video/SZQp2mRVU0g/видео.html
Grazie tante@@codingconmanuel
sull'hoisting manca l'esempio con var secondo me, perchè anche con l'esempio della arrow function vedrete che l'errore cambia a seconda se si usa const o var, invece con una variabile vedrete che con var non darà errore
Hai assolutamente ragione, aggiungere un esempio con var sarebbe stato utile per comprendere meglio l'hoisting! Grazie per il suggerimento. Ecco una spiegazione rapida:
Quando usi var:
console.log(x); // Risultato: undefined
var x = 5;
console.log(x); // Risultato: 5
La variabile x dichiarata con var viene, per tradurre alla lettera "issata", il che significa che la sua dichiarazione viene spostata in cima al suo contesto di esecuzione. Tuttavia, solo la dichiarazione viene issata, non l'assegnazione, quindi all'inizio x è undefined.
Ora confrontiamolo con let e const:
console.log(y); // Risultato: ReferenceError: y is not defined
let y = 5;
console.log(z); // Risultato: ReferenceError: z is not defined
const z = 5;
Con let e const, provare ad accedere alle variabili prima della loro dichiarazione genera un errore perché si trovano in una "zona morta temporale" (Temporal Dead Zone) fino alla loro inizializzazione.
Questi esempi dimostrano come l'hoisting con var permette l'accesso alle variabili prima che siano inizializzate, restituendo undefined, a differenza di let e const che generano un errore.
Ciò detto ricordo che var, nella programmazione JavaScript moderna, viene usato meno spesso, specialmente da quando let e const sono state aggiunte in ES6. Il motivo del declino nell'uso di var si può riassumere in due punti:
1. Scope: var ha uno scope funzionale, il che significa che le variabili dichiarate con var sono accessibili all'interno dell'intera funzione in cui sono dichiarate, indipendentemente dai blocchi di codice (come if o cicli). Al contrario, let e const hanno uno scope di blocco, rendendole accessibili solo all'interno del blocco in cui sono dichiarate. Questo aiuta a prevenire errori dovuti a sovrapposizioni o riutilizzi involontari di variabili.
2. Hoisting: Le variabili dichiarate con var sono soggette a hoisting, il che significa che possono essere usate prima della loro dichiarazione effettiva nel codice, sebbene inizialmente avranno il valore undefined. Questo può portare a confusioni e bug difficili da tracciare. let e const sono anch'esse soggette a hoisting, ma non si può accedere a queste variabili prima della loro dichiarazione effettiva nel codice a causa della cosiddetta "temporal dead zone", riducendo così gli errori.
var ha senso usarlo, oggi, solo nel caso di:
1. Compatibilità con vecchi browser
2. Specifiche tecniche particolari
In generale, l'uso di let e const è raccomandato per una programmazione più sicura e prevedibile. var è più come un vecchio cimelio di versioni precedenti di JavaScript, e il suo uso è spesso evitato in progetti nuovi o durante la revisione di codice legacy.
@@codingconmanuel perfetto
perchè per la ricorsione si deve dare importanza al concetto di termine di ricorsione per l'iterazione no? Il concetto di fine ricorsione è ovviamente importante ma trovo della stessa importanza il concetto di fine iterazione
Sia nella ricorsione che nell'iterazione, il concetto di "terminazione" è fondamentale per evitare cicli infiniti e per assicurarsi che il codice faccia esattamente quello che ci aspettiamo in un numero finito di passaggi.
La differenza chiave tra ricorsione e iterazione sta nel modo in cui gestiscono la terminazione:
🔁 Ricorsione: Il termine di ricorsione, o "caso base", è essenziale perché impedisce alla funzione di chiamare se stessa all'infinito. Ogni chiamata ricorsiva si avvicina sempre di più al caso base e, una volta raggiunto, la ricorsione si interrompe. La definizione stessa della funzione ricorsiva incorpora questo meccanismo di terminazione.
👀 Iterazione: Nell'iterazione, il controllo di terminazione viene eseguito all'inizio o alla fine di un ciclo (come nei cicli while o for). Qui, devi definire esplicitamente una condizione che determina quando il ciclo deve fermarsi. Questa condizione viene verificata ad ogni iterazione del ciclo.
Anche se il principio di avere un "punto di fine" è comune a entrambi i metodi, la loro implementazione e controllo sono molto diversi. Nella ricorsione, il termine è un requisito strutturale critico del processo di chiamata, mentre nell'iterazione è più un controllo di flusso esterno che decide la cessazione del ciclo. Proprio per questo, il caso base nella ricorsione tende ad essere enfatizzato più del controllo di terminazione nell'iterazione, ma come hai giustamente notato, entrambi sono cruciali per il corretto funzionamento del codice.