From 91c166fce08bb40ec24314e1ffa3f602a2e9c76e Mon Sep 17 00:00:00 2001
From: Andrea Longo <longoandrea.dev@gmail.com>
Date: Sat, 6 Mar 2021 14:49:42 +0100
Subject: [PATCH 1/3] translate article

---
 1-js/13-modules/02-import-export/article.md | 240 ++++++++++----------
 1 file changed, 120 insertions(+), 120 deletions(-)

diff --git a/1-js/13-modules/02-import-export/article.md b/1-js/13-modules/02-import-export/article.md
index 7f24d29ce..1bb6589d5 100644
--- a/1-js/13-modules/02-import-export/article.md
+++ b/1-js/13-modules/02-import-export/article.md
@@ -1,23 +1,23 @@
-# Export and Import
+# Export e Import
 
-Export and import directives have several syntax variants.
+Le direttive export e import esistono sotto forma di diverse varianti.
 
-In the previous article we saw a simple use, now let's explore more examples.
+Nell'articolo precedente, ne abbiamo visto un utilizzo molto semplice, ora esploriamo più esempi.
 
-## Export before declarations
+## Export prima della dichiarazione
 
-We can label any declaration as exported by placing `export` before it, be it a variable, function or a class.
+Possiamo etichettare una qualsiasi dichiarazione come esportata, con il prefisso `export`, sia che questa sia una variabile, una funzione o una classe.
 
-For instance, here all exports are valid:
+Ad esempio, i seguenti exports sono tutti validi:
 
 ```js
-// export an array
+// esportiamo un array
 *!*export*/!* let months = ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
 
-// export a constant
+// esportiamo una costante
 *!*export*/!* const MODULES_BECAME_STANDARD_YEAR = 2015;
 
-// export a class
+// esportiamo una classe
 *!*export*/!* class User {
   constructor(name) {
     this.name = name;
@@ -25,12 +25,12 @@ For instance, here all exports are valid:
 }
 ```
 
-````smart header="No semicolons after export class/function"
-Please note that `export` before a class or a function does not make it a [function expression](info:function-expressions). It's still a function declaration, albeit exported.
+````smart header="Non c'è bisogno del punto e virgola dopo l'export di una classe/funzione"
+Da notare che il termine `export` prima di una funzione, non la rende un'[espressione di funzione](info:function-expressions). Rimane sempre una dichiarazione di funzione, viene semplicemente esportata.
 
-Most JavaScript style guides don't recommend semicolons after function and class declarations.
+Molte style guide di JavaScript sconsigliano l'utilizzo del punto e virgola dopo la dichiarazione di una classe o funzione.
 
-That's why there's no need for a semicolon at the end of `export class` and `export function`:
+Questo è il motivo per cui non c'è alcun bisogno del punto e virgola dopo `export class` e `export function`:
 
 ```js
 export function sayHi(user) {
@@ -40,11 +40,11 @@ export function sayHi(user) {
 
 ````
 
-## Export apart from declarations
+## Export oltre alle dichiarazioni
 
-Also, we can put `export` separately.
+Inoltre, possiamo inserire `export` separatamente.
 
-Here we first declare, and then export:
+In questo caso, prima dichiariamo e successivamente esportiamo:
 
 ```js  
 // 📁 say.js
@@ -57,15 +57,15 @@ function sayBye(user) {
 }
 
 *!*
-export {sayHi, sayBye}; // a list of exported variables
+export {sayHi, sayBye}; // una lista di variabili esportate
 */!*
 ```
 
-...Or, technically we could put `export` above functions as well.
+...Oppure, tecnicamente, potremmo inserire `export` anche prima delle dichiarazioni delle funzioni.
 
 ## Import *
 
-Usually, we put a list of what to import in curly braces `import {...}`, like this:
+Solitamente, inseriamo una lista di ciò che vogliamo importare tra le parentesi graffe `import {...}`, in questo modo:
 
 ```js
 // 📁 main.js
@@ -77,7 +77,7 @@ sayHi('John'); // Hello, John!
 sayBye('John'); // Bye, John!
 ```
 
-But if there's a lot to import, we can import everything as an object using `import * as <obj>`, for instance:
+Ma ne caso in cui si fossero molti import, potremmo importare tutto come un oggetto, utilizzando `import * as <obj>`, ad esempio:
 
 ```js
 // 📁 main.js
@@ -89,13 +89,13 @@ say.sayHi('John');
 say.sayBye('John');
 ```
 
-At first sight, "import everything" seems such a cool thing, short to write, why should we ever explicitly list what we need to import?
+A prima vista, "importa tutto" sembra una cosa comoda, veloce da scrivere, quindi perché dovremmo esplicitare una lista di ciò che vogliamo importare?
 
-Well, there are few reasons.
+Ecco alcune ragioni valide.
 
-1. Modern build tools ([webpack](http://webpack.github.io) and others) bundle modules together and optimize them to speedup loading and remove unused stuff.
+1. Gli strumenti moderni di build ([webpack](http://webpack.github.io) ed altri) impacchettano i moduli in modo da ottimizzarli, velocizzarne il caricamento e rimuovere le cose inutili.
 
-    Let's say, we added a 3rd-party library `say.js` to our project with many functions:
+    Ipotizziamo di aggiungere una libreria di terze parti `say.js` al nostro progetto, che contiene molte funzioni:
     ```js
     // 📁 say.js
     export function sayHi() { ... }
@@ -103,21 +103,21 @@ Well, there are few reasons.
     export function becomeSilent() { ... }
     ```
 
-    Now if we only use one of `say.js` functions in our project:
+    Ora utilizziamo solamente una delle funzioni di `say.js` nel nostro progetto:
     ```js
     // 📁 main.js
     import {sayHi} from './say.js';
     ```
-    ...Then the optimizer will see that and remove the other functions from the bundled code, thus making the build smaller. That is called "tree-shaking".
+    ...Ora l'ottimizzazione se ne accorgerà e rimuoverà le altre funzioni dal codice compilato, rendendo il pacchetto più piccolo. Questo viene chiamato "tree-shaking".
 
-2. Explicitly listing what to import gives shorter names: `sayHi()` instead of `say.sayHi()`.
-3. Explicit list of imports gives better overview of the code structure: what is used and where. It makes code support and refactoring easier.
+2. Elencare esplicitamente ciò che vogliamo importare ci fornisce nomi più brevi: `sayHi()` piuttosto di `say.sayHi()`.
+3. Elencare esplicitamente ciò che vogliamo importare ci fornisce una migliore visione della struttura del codice: cosa viene utilizzato e dove. Rende la manutenibilità e il refactoring del codice più semplice.
 
 ## Import "as"
 
-We can also use `as` to import under different names.
+Possiamo anche utilizzare la keyword `as` per importare con nomi differenti.
 
-For instance, let's import `sayHi` into the local variable `hi` for brevity, and import `sayBye` as `bye`:
+Ad esempio, importiamo `sayHi` in una variabile locale `hi` per brevità, e `sayBye` come `bye`:
 
 ```js
 // 📁 main.js
@@ -131,9 +131,9 @@ bye('John'); // Bye, John!
 
 ## Export "as"
 
-The similar syntax exists for `export`.
+Una sintassi molto simile è disponibile per `export`.
 
-Let's export functions as `hi` and `bye`:
+Esportiamo le funzioni come `hi` e `bye`:
 
 ```js
 // 📁 say.js
@@ -141,7 +141,7 @@ Let's export functions as `hi` and `bye`:
 export {sayHi as hi, sayBye as bye};
 ```
 
-Now `hi` and `bye` are official names for outsiders, to be used in imports:
+Ora `hi` e `bye` sono i nomi ufficiali per chi le vede esternamente, quelli da utilizzare per gli import:
 
 ```js
 // 📁 main.js
@@ -153,95 +153,95 @@ say.*!*bye*/!*('John'); // Bye, John!
 
 ## Export default
 
-In practice, there are mainly two kinds of modules.
+Nella pratica, esistono principalmente due tipi di moduli.
 
-1. Modules that contain a library, pack of functions, like `say.js` above.
-2. Modules that declare a single entity, e.g. a module `user.js` exports only `class User`.
+1. Moduli che contengono una library, pacchetti di funzioni, come `say.js` visto sopra.
+2. Moduli che dichiarano una singola entità, esempio un modulo `user.js` che esporta solamente `class User`.
 
-Mostly, the second approach is preferred, so that every "thing" resides in its own module.
+Nella maggior parte dei casi, si preferisce il secondo approccio, in modo tale che "ogni cosa" stia nel suo modulo.
 
-Naturally, that requires a lot of files, as everything wants its own module, but that's not a problem at all. Actually, code navigation becomes easier if files are well-named and structured into folders.
+Naturalmente, questa pratica richiede l'utilizzo di molti files, poiché ogni cosa richiede il suo modulo, ma questo non è un problema. In realtà, la navigazione del codice diventa più semplice se tutti i file hanno dei nomi parlanti e sono ben strutturati all'interno di cartelle.
 
-Modules provide a special `export default` ("the default export") syntax to make the "one thing per module" way look better.
+I moduli forniscono una speciali sintassi, `export default` ("export di default"), per rendere la pratica "una cosa per modulo" più elegante.
 
-Put `export default` before the entity to export:
+E' sufficiente inserire `export default`, prima dell'entità da esportare:
 
 ```js
 // 📁 user.js
-export *!*default*/!* class User { // just add "default"
+export *!*default*/!* class User { // aggiungiamo "default"
   constructor(name) {
     this.name = name;
   }
 }
 ```
 
-There may be only one `export default` per file.
+Può esserci solamente un `export default` per file.
 
-...And then import it without curly braces:
+...E possiamo importarlo senza le parentesi graffe:
 
 ```js
 // 📁 main.js
-import *!*User*/!* from './user.js'; // not {User}, just User
+import *!*User*/!* from './user.js'; // non {User}, semplicemente User
 
 new User('John');
 ```
 
-Imports without curly braces look nicer. A common mistake when starting to use modules is to forget curly braces at all. So, remember, `import` needs curly braces for named exports and doesn't need them for the default one.
+Gli import senza parentesi graffe sono più eleganti. Un errore comune quando si inizia ad utilizzare i moduli è quello di dimenticarsi le parentesi graffe. Quindi, ricorda, `import` richiede le parentesi graffe per i named export, ma non le richiedere per i default export.
 
 | Named export | Default export |
 |--------------|----------------|
 | `export class User {...}` | `export default class User {...}` |
 | `import {User} from ...` | `import User from ...`|
 
-Technically, we may have both default and named exports in a single module, but in practice people usually don't mix them. A module has either named exports or the default one.
+Tecnicamente, potremmo avere sia il default che il named export nello stesso modulo, ma nella pratica gli sviluppatori non lo fanno. Un modulo può essere named export o default export.
 
-As there may be at most one default export per file, the exported entity may have no name.
+Poiché possiamo utilizzare al massimo un default export per file, l'entità esportata non richiede alcun nome.
 
-For instance, these are all perfectly valid default exports:
+Ad esempio, questi sono tutti export default validi:
 
 ```js
-export default class { // no class name
+export default class { // la classe non ha un nome
   constructor() { ... }
 }
 ```
 
 ```js
-export default function(user) { // no function name
+export default function(user) { // la funzione non ha un nome
   alert(`Hello, ${user}!`);
 }
 ```
 
 ```js
-// export a single value, without making a variable
+// esportiamo un valore, senza dichiarare la variabile
 export default ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
 ```
 
-Not giving a name is fine, because there is only one `export default` per file, so `import` without curly braces knows what to import.
+Non dare un nome va bene, poiché abbiamo un solo `export default` per file, quindi `import` senza parentesi graffe, sa cosa importare.
 
-Without `default`, such an export would give an error:
+Senza `default`, questo export genererebbe un errore:
 
 ```js
-export class { // Error! (non-default export needs a name)
+export class { // Errore! (non-default export richiedono un nome)
   constructor() {}
 }
 ```     
 
-### The "default" name
+### Il nome di "default"
 
-In some situations the `default` keyword is used to reference the default export.
+In alcune situazioni la keyword `default` per fare riferimento al default export.
 
-For example, to export a function separately from its definition:
+Ad esempio, per esportare una funzione separatamente dalla sua definizione:
 
 ```js
 function sayHi(user) {
   alert(`Hello, ${user}!`);
 }
 
-// same as if we added "export default" before the function
+// equivalente a "export default"
 export {sayHi as default};
 ```
 
-Or, another situation, let's say a module `user.js` exports one main "default" thing, and a few named ones (rarely the case, but it happens):
+Oppure, un'altra situazione, immaginiamo di avere un modulo `user.js` che esporta una "cosa" di default, ed un paio di altre con nome (accade raramente, ma è possibile):
 
 ```js
 // 📁 user.js
@@ -256,7 +256,7 @@ export function sayHi(user) {
 }
 ```
 
-Here's how to import the default export along with a named one:
+Vediamo come importare il default export insieme a quello named:
 
 ```js
 // 📁 main.js
@@ -265,38 +265,38 @@ import {*!*default as User*/!*, sayHi} from './user.js';
 new User('John');
 ```
 
-And, finally, if importing everything `*` as an object, then the `default` property is exactly the default export:
+E, infine, se importiamo tutto `*` come un oggetto, allora la proprietà di `default` corrisponde al default export:
 
 ```js
 // 📁 main.js
 import * as user from './user.js';
 
-let User = user.default; // the default export
+let User = user.default; // il default export
 new User('John');
 ```
 
-### A word against default exports
+### Una parola contro il default exports
 
-Named exports are explicit. They exactly name what they import, so we have that information from them; that's a good thing.
+I named export sono espliciti. Elencano esattamente il nome di ciò che vogliono importare, quindi avremo questa informazione (il nome) da loro; questa è sempre una buona cosa.
 
-Named exports force us to use exactly the right name to import:
+I named export ci forzano ad utilizzare il nome esatto di ciò che vogliamo importare:
 
 ```js
 import {User} from './user.js';
-// import {MyUser} won't work, the name must be {User}
+// import {MyUser} non funzionerebbe, il nome deve essere {User}
 ```
 
-...While for a default export, we always choose the name when importing:
+...Mentre per un default export, noi possiamo decidere il nome in fase di importazione:
 
 ```js
-import User from './user.js'; // works
-import MyUser from './user.js'; // works too
-// could be import Anything... and it'll still work
+import User from './user.js'; // funziona
+import MyUser from './user.js'; // funziona
+// potrebbe essere anche import Anything... e comunque funzionerebbe
 ```
 
-So team members may use different names to import the same thing, and that's not good.
+Quindi i membri del team potrebbero utilizzare nomi differenti per importare le stesse cose, e questa non è una buona cosa.
 
-Usually, to avoid that and keep the code consistent, there's a rule that imported variables should correspond to file names, e.g:
+Solitamente, per evitare questo problema, e mantenere il codice consistente, ci si pone come regole che le variabili importate debbano corrispondere ai nomi dei file, esempio:
 
 ```js
 import User from './user.js';
@@ -305,13 +305,13 @@ import func from '/path/to/func.js';
 ...
 ```
 
-Still, some teams consider it a serious drawback of default exports. So they prefer to always use named exports. Even if only a single thing is exported, it's still exported under a name, without `default`.
+Ancora, alcuni team ritengono questo uno svantaggio piuttosto serio dei default export. Quindi preferiscono utilizzare i named exports. Anche se viene esportata solamente una cosa, questa viene esportata con un nome, senza `default`.
 
-That also makes re-export (see below) a little bit easier.
+Questo rende il re-export (vedi sotto) più semplice.
 
 ## Re-export
 
-"Re-export" syntax `export ... from ...` allows to import things and immediately export them (possibly under another name), like this:
+La sintassi di "re-export", `export ... from ...` ci consente di importare cose ed esportarle immediatamente (eventualmente con un altro nome), come nell'esempio:
 
 ```js
 export {sayHi} from './say.js'; // re-export sayHi
@@ -319,11 +319,11 @@ export {sayHi} from './say.js'; // re-export sayHi
 export {default as User} from './user.js'; // re-export default
 ```
 
-Why would that be needed? Let's see a practical use case.
+Perché questo dovrebbe essere necessario? Vediamolo con un esempio pratico.
 
-Imagine, we're writing a "package": a folder with a lot of modules, with some of the functionality exported outside (tools like NPM allow us to publish and distribute such packages, but we don't have to use them), and many modules are just "helpers", for internal use in other package modules.
+Immaginiamo di scrivere un "package" (pacchetto): una cartella contenente molti moduli, con alcune funzionalità esportate esternamente (strumenti come NPM ci consentono di pubblicare e distribuire questi pacchetti, ma non li utilizzeremo), e molti moduli sono semplicemente "helpers", per uso interno in altri moduli del package.
 
-The file structure could be like this:
+La struttura dei file potrebbe essere qualcosa del genere:
 ```
 auth/
     index.js  
@@ -337,56 +337,56 @@ auth/
         ...
 ```
 
-We'd like to expose the package functionality via a single entry point.
+Vorremmo poi esporre le funzionalità del package con un singolo entry point (punto di ingresso).
 
-In other words, a person who would like to use our package, should import only from the "main file" `auth/index.js`.
+In altre parole, la persona che volesse utilizzare il nostro package, dovrebbe importare solamente il "main file" `auth/index.js`.
 
-Like this:
+Come vediamo qui:
 
 ```js
 import {login, logout} from 'auth/index.js'
 ```
 
-The "main file", `auth/index.js` exports all the functionality that we'd like to provide in our package.
+Il "main file", `auth/index.js` esporta tutte le funzionalità che vogliamo fornire con il nostro package.
 
-The idea is that outsiders, other programmers who use our package, should not meddle with its internal structure, search for files inside our package folder. We export only what's necessary in `auth/index.js` and keep the rest hidden from prying eyes.
+L'idea è che gli esterni, gli altri programmatori che utilizzano il nostro package, non dovrebbero preoccuparsi della struttura interna, alla ricerca dei file all'interno del nostro package. Esportiamo solamente ciò che è necessario in `auth/index.js` e teniamo il resto nascosto da occhi indiscreti.
 
-As the actual exported functionality is scattered among the package, we can import it into `auth/index.js` and export from it:
+Poiché le funzionalità di export sono sparpagliate nel package, possiamo importarle in `auth/index.js` ed esportarle da li:
 
 ```js
 // 📁 auth/index.js
 
-// import login/logout and immediately export them
+// import login/logout e li esportiamo immediatamente
 import {login, logout} from './helpers.js';
 export {login, logout};
 
-// import default as User and export it
+// import default come User e lo esportiamo
 import User from './user.js';
 export {User};
 ...
 ```
 
-Now users of our package can `import {login} from "auth/index.js"`.
+Ora, gli utenti del nostro package possono `import {login} from "auth/index.js"`.
 
-The syntax `export ... from ...` is just a shorter notation for such import-export:
+La sintassi `export ... from ...` è semplicemente una notazione più breve per questi import-export:
 
 ```js
 // 📁 auth/index.js
 // re-export login/logout 
 export {login, logout} from './helpers.js';
 
-// re-export the default export as User
+// re-export il default export as User
 export {default as User} from './user.js';
 ...
 ```
 
-The notable difference of `export ... from` compared to `import/export` is that re-exported modules aren't available in the current file. So inside the above example of `auth/index.js` we can't use re-exported `login/logout` functions. 
+Un'importante differenza tra `export ... from` e `import/export`, è che i moduli ri-esportati non sono disponibili nel file corrente. Quindi, guardando l'esempio sopra `auth/index.js`, non possiamo utilizzare le funzioni ri-esportate `login/logout`. 
 
-### Re-exporting the default export
+### Re-exporting il default export
 
-The default export needs separate handling when re-exporting.
+I default export richiedono una gestione separata quando li ri-esportiamo.
 
-Let's say we have `user.js` with the `export default class User` and would like to re-export it:
+Ipotizziamo di avere `user.js` con `export default class User`, e di volerlo ri-esportare:
 
 ```js
 // 📁 user.js
@@ -395,71 +395,71 @@ export default class User {
 }
 ```
 
-We can come across two problems with it:
+Potremmo incontrare due problemi:
 
-1. `export User from './user.js'` won't work. That would lead to a syntax error.
+1. `export User from './user.js'` non funziona. Genererebbe un errore sintattico.
 
-    To re-export the default export, we have to write `export {default as User}`, as in the example above.    
+    Per ri-esportare il default export, dobbiamo scrivere `export {default as User}`, come nell'esempio sopra.
 
-2. `export * from './user.js'` re-exports only named exports, but ignores the default one.
+2. `export * from './user.js'` ri-esporta solamente i named exports, ma ignora quelli di default.
 
-    If we'd like to re-export both named and the default export, then two statements are needed:
+    Nel caso in cui volessimo ri-esportare sia i named che i defaul export, allora abbiamo bisogno di due istruzioni:
     ```js
-    export * from './user.js'; // to re-export named exports
-    export {default} from './user.js'; // to re-export the default export
+    export * from './user.js'; // per ri-esportare i named exports
+    export {default} from './user.js'; // per ri-esportare i default export
     ```
 
-Such oddities of re-exporting a default export are one of the reasons why some developers don't like default exports and prefer named ones.
+Queste stranezza nella ri-esportazione di un default export, è una delle ragioni del perché alcuni sviluppatori non amano i default export, ma preferiscono quelli di default.
 
-## Summary
+## Riepilogo
 
-Here are all types of `export` that we covered in this and previous articles.
+Vediamo tutti i tipi di `export` che abbiamo studiato in questo articolo e nei precedenti.
 
-You can check yourself by reading them and recalling what they mean:
+Puoi controllarli tu stesso, leggendoli e provando a ricordarne il significato:
 
-- Before declaration of a class/function/..:
+- Prima della dichiarazione di una classe/funzione/..:
   - `export [default] class/function/variable ...`
-- Standalone export:
+- Export indipendente:
   - `export {x [as y], ...}`.
 - Re-export:
   - `export {x [as y], ...} from "module"`
-  - `export * from "module"` (doesn't re-export default).
-  - `export {default [as y]} from "module"` (re-export default).
+  - `export * from "module"` (non ri-esporta i default export).
+  - `export {default [as y]} from "module"` (ri-esporta i default export).
 
 Import:
 
-- Named exports from module:
+- Named exports da un modulo:
   - `import {x [as y], ...} from "module"`
 - Default export:  
   - `import x from "module"`
   - `import {default as x} from "module"`
-- Everything:
+- Tutto:
   - `import * as obj from "module"`
-- Import the module (its code runs), but do not assign it to a variable:
+- Importa il modulo (il suo codice viene eseguito), ma non lo assegna ad alcuna variabile:
   - `import "module"`
 
-We can put `import/export` statements at the top or at the bottom of a script, that doesn't matter.
+Possiamo inserire le istruzioni di `import/export` in cima o in cosa allo script, non ha importanza.
 
-So, technically this code is fine:
+Quindi, tecnicamente, questo codice funziona:
 ```js
 sayHi();
 
 // ...
 
-import {sayHi} from './say.js'; // import at the end of the file
+import {sayHi} from './say.js'; // import alla fine del file
 ```
 
-In practice imports are usually at the start of the file, but that's only for more convenience.
+Nella pratica gli import sono posizionati all'inizio del file, ma solo per comodità.
 
-**Please note that import/export statements don't work if inside `{...}`.**
+**Da notare che le istruzioni di import/export non funzionano all'interno di `{...}`.**
 
-A conditional import, like this, won't work:
+Un import condizionale, come questo, non funziona:
 ```js
 if (something) {
-  import {sayHi} from "./say.js"; // Error: import must be at top level
+  import {sayHi} from "./say.js"; // Errore: import deve essere nello scope principale
 }
 ```
 
-...But what if we really need to import something conditionally? Or at the right time? Like, load a module upon request, when it's really needed?
+...E nel caso in cui volessimo veramente importare qualcosa secondo una condizione? Oppure al momento giusto? Ad esempio, caricando un modulo in seguito ad una richiesta, nel momento in cui è veramente necessario?
 
-We'll see dynamic imports in the next article.
+Vederemo i dynamic imports nel prossimo articolo.

From 95bb5e4e5025be74cdafd51ed510c99b928a7463 Mon Sep 17 00:00:00 2001
From: Andrea <45577511+longo-andrea@users.noreply.github.com>
Date: Sun, 7 Mar 2021 09:47:47 +0100
Subject: [PATCH 2/3] Apply suggestions from code review

Co-authored-by: Dorin David <70648503+Dorin-David@users.noreply.github.com>
---
 1-js/13-modules/02-import-export/article.md | 30 ++++++++++-----------
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/1-js/13-modules/02-import-export/article.md b/1-js/13-modules/02-import-export/article.md
index 1bb6589d5..6eb2178af 100644
--- a/1-js/13-modules/02-import-export/article.md
+++ b/1-js/13-modules/02-import-export/article.md
@@ -28,7 +28,7 @@ Ad esempio, i seguenti exports sono tutti validi:
 ````smart header="Non c'è bisogno del punto e virgola dopo l'export di una classe/funzione"
 Da notare che il termine `export` prima di una funzione, non la rende un'[espressione di funzione](info:function-expressions). Rimane sempre una dichiarazione di funzione, viene semplicemente esportata.
 
-Molte style guide di JavaScript sconsigliano l'utilizzo del punto e virgola dopo la dichiarazione di una classe o funzione.
+Molte guide style di JavaScript sconsigliano l'utilizzo del punto e virgola dopo la dichiarazione di una classe o funzione.
 
 Questo è il motivo per cui non c'è alcun bisogno del punto e virgola dopo `export class` e `export function`:
 
@@ -77,7 +77,7 @@ sayHi('John'); // Hello, John!
 sayBye('John'); // Bye, John!
 ```
 
-Ma ne caso in cui si fossero molti import, potremmo importare tutto come un oggetto, utilizzando `import * as <obj>`, ad esempio:
+Ma nel caso in cui ci fossero molti import, potremmo importare tutto come un oggetto, utilizzando `import * as <obj>`, ad esempio:
 
 ```js
 // 📁 main.js
@@ -153,18 +153,18 @@ say.*!*bye*/!*('John'); // Bye, John!
 
 ## Export default
 
-Nella pratica, esistono principalmente due tipi di moduli.
+In pratica, esistono principalmente due tipi di moduli.
 
 1. Moduli che contengono una library, pacchetti di funzioni, come `say.js` visto sopra.
 2. Moduli che dichiarano una singola entità, esempio un modulo `user.js` che esporta solamente `class User`.
 
-Nella maggior parte dei casi, si preferisce il secondo approccio, in modo tale che "ogni cosa" stia nel suo modulo.
+Nella maggior parte dei casi, si preferisce il secondo approccio, in modo tale che ogni "cosa" stia nel suo modulo.
 
-Naturalmente, questa pratica richiede l'utilizzo di molti files, poiché ogni cosa richiede il suo modulo, ma questo non è un problema. In realtà, la navigazione del codice diventa più semplice se tutti i file hanno dei nomi parlanti e sono ben strutturati all'interno di cartelle.
+Naturalmente, questa pratica richiede l'utilizzo di molti files, poiché ogni cosa richiede il suo modulo, ma questo non è un problema. In realtà, la navigazione del codice diventa più semplice se tutti i file hanno dei nomi descrittivi e sono ben strutturati all'interno di cartelle.
 
-I moduli forniscono una speciali sintassi, `export default` ("export di default"), per rendere la pratica "una cosa per modulo" più elegante.
+I moduli forniscono una speciale sintassi, `export default` ("export di default"), per rendere la pratica "una cosa per modulo" più elegante.
 
-E' sufficiente inserire `export default`, prima dell'entità da esportare:
+E' sufficiente inserire `export default` prima dell'entità da esportare:
 
 ```js
 // 📁 user.js
@@ -193,7 +193,7 @@ Gli import senza parentesi graffe sono più eleganti. Un errore comune quando si
 | `export class User {...}` | `export default class User {...}` |
 | `import {User} from ...` | `import User from ...`|
 
-Tecnicamente, potremmo avere sia il default che il named export nello stesso modulo, ma nella pratica gli sviluppatori non lo fanno. Un modulo può essere named export o default export.
+Tecnicamente, potremmo avere sia il default che il named export nello stesso modulo, ma in pratica gli sviluppatori non lo fanno. Un modulo può essere named export o default export.
 
 Poiché possiamo utilizzare al massimo un default export per file, l'entità esportata non richiede alcun nome.
 
@@ -286,17 +286,17 @@ import {User} from './user.js';
 // import {MyUser} non funzionerebbe, il nome deve essere {User}
 ```
 
-...Mentre per un default export, noi possiamo decidere il nome in fase di importazione:
+...Mentre per un default export, possiamo decidere il nome in fase di importazione:
 
 ```js
 import User from './user.js'; // funziona
 import MyUser from './user.js'; // funziona
-// potrebbe essere anche import Anything... e comunque funzionerebbe
+// potrebbe essere anche import Anything... e funzionerebbe comunque
 ```
 
 Quindi i membri del team potrebbero utilizzare nomi differenti per importare le stesse cose, e questa non è una buona cosa.
 
-Solitamente, per evitare questo problema, e mantenere il codice consistente, ci si pone come regole che le variabili importate debbano corrispondere ai nomi dei file, esempio:
+Solitamente, per evitare questo problema, e mantenere il codice consistente, ci si pone come regola che le variabili importate debbano corrispondere ai nomi dei file, esempio:
 
 ```js
 import User from './user.js';
@@ -351,7 +351,7 @@ Il "main file", `auth/index.js` esporta tutte le funzionalità che vogliamo forn
 
 L'idea è che gli esterni, gli altri programmatori che utilizzano il nostro package, non dovrebbero preoccuparsi della struttura interna, alla ricerca dei file all'interno del nostro package. Esportiamo solamente ciò che è necessario in `auth/index.js` e teniamo il resto nascosto da occhi indiscreti.
 
-Poiché le funzionalità di export sono sparpagliate nel package, possiamo importarle in `auth/index.js` ed esportarle da li:
+Poiché le funzionalità di export sono sparpagliate nel package, possiamo importarle in `auth/index.js` ed esportarle da lì:
 
 ```js
 // 📁 auth/index.js
@@ -403,13 +403,13 @@ Potremmo incontrare due problemi:
 
 2. `export * from './user.js'` ri-esporta solamente i named exports, ma ignora quelli di default.
 
-    Nel caso in cui volessimo ri-esportare sia i named che i defaul export, allora abbiamo bisogno di due istruzioni:
+    Nel caso in cui volessimo ri-esportare sia i named che i defaul export, allora avremmo bisogno di due istruzioni:
     ```js
     export * from './user.js'; // per ri-esportare i named exports
     export {default} from './user.js'; // per ri-esportare i default export
     ```
 
-Queste stranezza nella ri-esportazione di un default export, è una delle ragioni del perché alcuni sviluppatori non amano i default export, ma preferiscono quelli di default.
+Queste stranezze nella ri-esportazione di un default export sono tra le ragioni del per cui alcuni sviluppatori non amano i default export, ma preferiscono quelli named.
 
 ## Riepilogo
 
@@ -438,7 +438,7 @@ Import:
 - Importa il modulo (il suo codice viene eseguito), ma non lo assegna ad alcuna variabile:
   - `import "module"`
 
-Possiamo inserire le istruzioni di `import/export` in cima o in cosa allo script, non ha importanza.
+Possiamo inserire le istruzioni di `import/export` in cima o in coda allo script, non ha importanza.
 
 Quindi, tecnicamente, questo codice funziona:
 ```js

From 0434d79417c588f28bfc3ff42af9a311680645b9 Mon Sep 17 00:00:00 2001
From: Andrea <45577511+longo-andrea@users.noreply.github.com>
Date: Sun, 7 Mar 2021 20:53:45 +0100
Subject: [PATCH 3/3] Apply suggestions from code review

Co-authored-by: Simone Pasini <66781510+pasor1@users.noreply.github.com>
---
 1-js/13-modules/02-import-export/article.md | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/1-js/13-modules/02-import-export/article.md b/1-js/13-modules/02-import-export/article.md
index 6eb2178af..cd3b68d76 100644
--- a/1-js/13-modules/02-import-export/article.md
+++ b/1-js/13-modules/02-import-export/article.md
@@ -28,7 +28,7 @@ Ad esempio, i seguenti exports sono tutti validi:
 ````smart header="Non c'è bisogno del punto e virgola dopo l'export di una classe/funzione"
 Da notare che il termine `export` prima di una funzione, non la rende un'[espressione di funzione](info:function-expressions). Rimane sempre una dichiarazione di funzione, viene semplicemente esportata.
 
-Molte guide style di JavaScript sconsigliano l'utilizzo del punto e virgola dopo la dichiarazione di una classe o funzione.
+Molte *style guides* di JavaScript sconsigliano l'utilizzo del punto e virgola dopo la dichiarazione di una classe o funzione.
 
 Questo è il motivo per cui non c'è alcun bisogno del punto e virgola dopo `export class` e `export function`:
 
@@ -155,8 +155,8 @@ say.*!*bye*/!*('John'); // Bye, John!
 
 In pratica, esistono principalmente due tipi di moduli.
 
-1. Moduli che contengono una library, pacchetti di funzioni, come `say.js` visto sopra.
-2. Moduli che dichiarano una singola entità, esempio un modulo `user.js` che esporta solamente `class User`.
+1. Moduli che contengono una libreria: pacchetti di funzioni, come `say.js` visto sopra.
+2. Moduli che dichiarano una singola entità: esempio un modulo `user.js` che esporta solamente `class User`.
 
 Nella maggior parte dei casi, si preferisce il secondo approccio, in modo tale che ogni "cosa" stia nel suo modulo.
 
@@ -277,7 +277,7 @@ new User('John');
 
 ### Una parola contro il default exports
 
-I named export sono espliciti. Elencano esattamente il nome di ciò che vogliono importare, quindi avremo questa informazione (il nome) da loro; questa è sempre una buona cosa.
+I named export sono espliciti, elencano esattamente il nome di ciò che vogliono importare. Avere in chiaro questa informazione (il nome), è sempre una buona cosa.
 
 I named export ci forzano ad utilizzare il nome esatto di ciò che vogliamo importare:
 
@@ -294,7 +294,7 @@ import MyUser from './user.js'; // funziona
 // potrebbe essere anche import Anything... e funzionerebbe comunque
 ```
 
-Quindi i membri del team potrebbero utilizzare nomi differenti per importare le stesse cose, e questa non è una buona cosa.
+Quindi i membri del team possono utilizzare nomi differenti per importare le stesse cose, e questa non è una buona cosa.
 
 Solitamente, per evitare questo problema, e mantenere il codice consistente, ci si pone come regola che le variabili importate debbano corrispondere ai nomi dei file, esempio:
 
@@ -321,7 +321,7 @@ export {default as User} from './user.js'; // re-export default
 
 Perché questo dovrebbe essere necessario? Vediamolo con un esempio pratico.
 
-Immaginiamo di scrivere un "package" (pacchetto): una cartella contenente molti moduli, con alcune funzionalità esportate esternamente (strumenti come NPM ci consentono di pubblicare e distribuire questi pacchetti, ma non li utilizzeremo), e molti moduli sono semplicemente "helpers", per uso interno in altri moduli del package.
+Immaginiamo di scrivere un "package" (pacchetto): una cartella contenente molti moduli, con alcune funzionalità esportate esternamente (strumenti come NPM ci consentono di pubblicare e distribuire questi pacchetti, ma non li utilizzeremo), e con molti moduli che sono semplicemente "helpers", per uso interno in altri moduli del package.
 
 La struttura dei file potrebbe essere qualcosa del genere:
 ```
@@ -349,18 +349,18 @@ import {login, logout} from 'auth/index.js'
 
 Il "main file", `auth/index.js` esporta tutte le funzionalità che vogliamo fornire con il nostro package.
 
-L'idea è che gli esterni, gli altri programmatori che utilizzano il nostro package, non dovrebbero preoccuparsi della struttura interna, alla ricerca dei file all'interno del nostro package. Esportiamo solamente ciò che è necessario in `auth/index.js` e teniamo il resto nascosto da occhi indiscreti.
+L'idea è che gli esterni, gli altri programmatori che utilizzano il nostro package, non debbano preoccuparsi della struttura interna e o di cercare files tra le cartelle in esso contenute. Esportiamo solamente ciò che è necessario in `auth/index.js` e teniamo il resto nascosto da occhi indiscreti.
 
 Poiché le funzionalità di export sono sparpagliate nel package, possiamo importarle in `auth/index.js` ed esportarle da lì:
 
 ```js
 // 📁 auth/index.js
 
-// import login/logout e li esportiamo immediatamente
+// importiamo login/logout e li esportiamo immediatamente
 import {login, logout} from './helpers.js';
 export {login, logout};
 
-// import default come User e lo esportiamo
+// importiamo default come User e lo esportiamo
 import User from './user.js';
 export {User};
 ...