` mostra valori sempre crescenti di `i`, come se fosse una sorta di barra di caricamento.
+
+## Caso d'uso 3: fare qualcosa dopo l'evento
-## Use case 3: doing something after the event
+In un gestore di evento, potremmo decidere di postporre alcune azioni, fino a che l'evento non risalga i vari livelli dello stack (bubbling up) e non venga gestito su tutti questi livelli.
+Possiamo farlo, avvolgendo (wrapping) il codice all'interno di istruzioni `setTimeout` a ritardo zero.
-In an event handler we may decide to postpone some actions until the event bubbled up and was handled on all levels. We can do that by wrapping the code in zero delay `setTimeout`.
+Nel capitolo
abbiamo visto un esempio: dell'evento custom `menu-open`, viene fatto il dispatch dentro `setTimeout`, così che esso viene richiamato dopo che l'evento click è stato del tutto gestito.
-In the chapter we saw an example: custom event `menu-open` is dispatched in `setTimeout`, so that it happens after the "click" event is fully handled.
```js
menu.onclick = function() {
// ...
-
- // create a custom event with the clicked menu item data
+ //crea un evento custom con l'elemento dati cliccato sul menu'
let customEvent = new CustomEvent("menu-open", {
bubbles: true
});
- // dispatch the custom event asynchronously
+ //dispatch dell'evento custom in maniera asincrona
setTimeout(() => menu.dispatchEvent(customEvent));
};
```
-## Macrotasks and Microtasks
-Along with *macrotasks*, described in this chapter, there exist *microtasks*, mentioned in the chapter .
+## Macrotasks e Microtasks
+
+Insieme ai *macrotasks*, descritti in questo capitolo, esistono i *microtasks*, menzionati nel capitolo .
-Microtasks come solely from our code. They are usually created by promises: an execution of `.then/catch/finally` handler becomes a microtask. Microtasks are used "under the cover" of `await` as well, as it's another form of promise handling.
+I microtasks provengono esclusivamente dal nostro codice. Solitamente vengono creati dalle promises: una esecuzione di un gestore `.then/catch/finally` diventa un microtask. I microtasks vengono usati anche "sotto copertura" dagli `await`, dato che anche questi non sono altro che un'altra forma di gestione di promises.
-There's also a special function `queueMicrotask(func)` that queues `func` for execution in the microtask queue.
+C'è anche una funzione speciale `queueMicrotask(func)` che accoda `func` per l'esecuzione nella coda dei microtask.
-**Immediately after every *macrotask*, the engine executes all tasks from *microtask* queue, prior to running any other macrotasks or rendering or anything else.**
+**Immediatamente dopo ogni *macrotask*, il motore esegue tutti i task dalla coda *microtask*, prima di ricominciare a eseguire ogni altro macrotask o renderizzare o qualunque altra cosa.**
-For instance, take a look:
+Per esempio, guardate questo:
```js run
setTimeout(() => alert("timeout"));
@@ -257,23 +252,24 @@ Promise.resolve()
alert("code");
```
-What's going to be the order here?
+Cosa succederà all'ordine delle operazioni in questo script?
-1. `code` shows first, because it's a regular synchronous call.
-2. `promise` shows second, because `.then` passes through the microtask queue, and runs after the current code.
-3. `timeout` shows last, because it's a macrotask.
+1. `code` viene mostrato per primo, dato che è un chiamata regolare e sincrona.
+2. `promise` viene mostrato per secondo, perchè `.then` passa attraverso la coda di microtask, e viene eseguito dopo il codice corrente.
+3. `timeout` viene mostrato come ultimo perchè è anhe questo un microtask.
-The richer event loop picture looks like this:
+L'immagine più esausitva di un event loop è questa:
-**All microtasks are completed before any other event handling or rendering or any other macrotask takes place.**
+**Tutti i microtasks vengono completati prima di ogni altra gestione degli eventi o rendering o qualunque altro macrotask che prende parte nell'esecuzione**
-That's important, as it guarantees that the application environment is basically the same (no mouse coordinate changes, no new network data, etc) between microtasks.
+Questo è importante perchè garantisce che l'ambiente applicativo rimanga intatto (nessuna modifica alle coordinate del puntatore del mouse, nessun dato dalle reti, etc) tra i vari microtasks.
-If we'd like to execute a function asynchronously (after the current code), but before changes are rendered or new events handled, we can schedule it with `queueMicrotask`.
+Se volessimo eseguire una funzione in maniera asincrona (dopo il codice in esecuzione), ma prima che avvengano cambiamenti nella finestra del browser, o che nuovi eventi vengano gestiti, potremmo schedularla con `queueMicrotask`.
-Here's an example with "counting progress bar", similar to the one shown previously, but `queueMicrotask` is used instead of `setTimeout`. You can see that it renders at the very end. Just like the synchronous code:
+Questo qui è un esempio della funzion "conteggio barra di progresso", del tutto simile alla precedente, ma vengono usati `queueMicrotask` invece di `setTimeout`.
+Come puoi notare, renderizza il valore del conteggio alla fine. Esattamente come se fosse del codice sincrono:
```html run
@@ -282,62 +278,58 @@ Here's an example with "counting progress bar", similar to the one shown previou
let i = 0;
function count() {
-
- // do a piece of the heavy job (*)
+ //faccio un pezzetto di lavoro pesante (*)
do {
i++;
progress.innerHTML = i;
} while (i % 1e3 != 0);
if (i < 1e6) {
- *!*
- queueMicrotask(count);
- */!*
+ queueMicrotask(count);
}
-
}
count();
```
-## Summary
+## Conclusioni
-The richer event loop picture may look like this:
+L'immagine più esausitva di un event loop è questa:
-The more detailed algorithm of the event loop (though still simplified compare to the [specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)):
+Questo è il più dettagliato algoritmo dell'event loop: (sebbene ancora semplicistico rispetto alla [specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)):
-1. Dequeue and run the oldest task from the *macrotask* queue (e.g. "script").
-2. Execute all *microtasks*:
- - While the microtask queue is not empty:
- - Dequeue and run the oldest microtask.
-3. Render changes if any.
-4. If the macrotask queue is empty, wait till a macrotask appears.
-5. Go to step 1.
+1. Rimuovi dalla coda ed esegui il task meno recente dalla coda dei *macrotask* (ad esempio "script").
+2. Esegui tutti i *microtasks*:
+ - Se la cosa dei microtask non è vuota:
+ - Rimuovi dalla coda ed esegui il meno recente dei microtask.
+3. Renderizza le modifiche se ve ne sono.
+4. Se la coda dei macrotask è vuota, vai in sleep fino al prossimo macrotask.
+5. Vai al passo 1.
-To schedule a new *macrotask*:
-- Use zero delayed `setTimeout(f)`.
+Per schedulare un nuovo *macrotask*:
+- Usa un `setTimeout(f)` ritardo zero.
-That may be used to split a big calculation-heavy task into pieces, for the browser to be able to react on user events and show progress between them.
+Questo potrebbe essere usato per divitere task di calcolo pesante in pezzi più piccoli, di modo che nello spazio tra questi, il browser possa eseguire altre operazioni.
-Also, used in event handlers to schedule an action after the event is fully handled (bubbling done).
+Inoltre, vengono usati nei gestori degli eventi per schedulre una azione dopo che l'evento è stato del tutto gestito (bubbling completato)
-To schedule a new *microtask*
-- Use `queueMicrotask(f)`.
-- Also promise handlers go through the microtask queue.
+Per schedulare un nuovo *microtask*
+- Usa `queueMicrotask(f)`.
+- Anche i gestori promise passando attraverso la coda dei microtask.
-There's no UI or network event handling between microtasks: they run immediately one after another.
+Non ci possono essere gestioni di UI o di networking tra i microtask, perchè i microtasks vengono eseguiti immediatamente uno dopo l'altro.
-So one may want to `queueMicrotask` to execute a function asynchronously, but within the environment state.
+Ma cosa succederebbe se uno volesse che la coda `queueMicrotask` eseguisse una funzione in maniera asincrona, mantenendo però il contesto dell'ambiente.
```smart header="Web Workers"
-For long heavy calculations that shouldn't block the event loop, we can use [Web Workers](https://html.spec.whatwg.org/multipage/workers.html).
+Per lunghi calcoli pesanti che non possono bloccare l'event loop, possiamo usare i [Web Workers](https://html.spec.whatwg.org/multipage/workers.html).
-That's a way to run code in another, parallel thread.
+I Web Workers sono un modo per eseguire del codice in un altro thread parallelo.
-Web Workers can exchange messages with the main process, but they have their own variables, and their own event loop.
+I Web Workers possono scambiare messaggi con il processo principale, ma hanno le loro variabili ed i loro event loop.
-Web Workers do not have access to DOM, so they are useful, mainly, for calculations, to use multiplle CPU cores simultaneously.
+I Web Workers non hanno accesso al DOM, quindi sono adatti principalmente per i calcoli, per usare contemporaneamente più cores della CPU.
```