iliakan review

Author: ca11ado

1-js/13-modules/02-import-export/article.md

@@ -8,7 +8,7 @@
 
 Мы можем пометить любое объявление как экспортируемое, разместив `export` перед ним, будь то переменная, функция или класс.
 
-Например, все следующие экспорты валидны:
+Например, все следующие экспорты допустимы:
 
 ```js
 // экспорт массива
@@ -61,7 +61,7 @@ export {sayHi, sayBye}; // список экспортируемых перем
 */!*
 ```
 
-...Или, технически, мы так же можем расположить `export` выше функций.
+...Или, технически, мы также можем расположить `export` выше функций.
 
 ## Импорт *
 
@@ -103,15 +103,15 @@ say.sayBye('John');
     export function becomeSilent() { ... }
     ```
 
-    Теперь, если нам на самом деле в проекте нужна только одна из них:
+    Теперь, если из этой библиотеки в проекте мы используем только одну функцию:
     ```js
     // 📁 main.js
     import {sayHi} from './lib.js';
     ```
     ...Тогда оптимизатор автоматически определит это и полностью удалит другие функции из собранного кода, тем самым делая код меньше. Это называется "tree-shaking".
 
 2. Явное перечисляя то, что хотим импортировать, мы получаем более короткие имена: `sayHi()` вместо `lib.sayHi()`.
-3. При явных импортах упрощается беглый обзор кода: что и где используется. Это упрощает поддержку и рефакторинг кода.
+3. Явный импорт делает код более понятным, позволяет увидеть, что именно и где используется. Это упрощает поддержку и рефакторинг кода.
 
 ## Импорт "как"
 
@@ -155,15 +155,15 @@ say.bye('John'); // Bye, John!
 
 До сих поры мы видели, как экспортировать/импортировать вещи, опционально под другими именами.
 
-На практике модули могут содержать:
+На практике модули обычно содержат одно из:
 - Либо библиотеку, набор функций, как `lib.js`.
 - Либо сущность, например `class User`, определенную в `user.js`. Во всём модуле есть только этот класс.
 
 По большей части, предпочтителен второй подход, чтобы каждая "вещь" находилась в своём собственном модуле.
 
-Естественно, это требует большого количества файлов, так как всё находится в своём модуле, но это не проблема. На самом деле, навигация по коду становится проще, если у файлов хорошие названия и всё структурировано по папкам.
+Естественно, потребуется много файлов, если для всего делать отдельный модуль, но это не проблема. Так даже удобнее: навигация по проекту становится проще, особенно если у файлов хорошие имена, и они структурированы по папкам.
 
-Модули предоставляют специальный синтаксис `export default`, чтобы вариант "одна вещь в одном модуле" выглядел лучше.
+Модули предоставляют специальный синтаксис `export default` для второго подхода.
 
 Для этого требуются следующие `export` и `import` инструкции:
 
@@ -190,7 +190,7 @@ import *!*User*/!* from './user.js'; // не {User}, просто User
 new User('John');
 ```
 
-Импорты без фигурных скобок выглядят лучше. Обычная ошибка для начинающих использовать модули: забыть про фигурные скобки совсем. Так что, помните, фигурные скобки необходимы только в случае именованного импорта, для импорта по-умолчанию они не нужны.
+Импорты без фигурных скобок выглядят красивее. Обычная ошибка начинающих: забыть про фигурные скобки. Фигурные скобки необходимы в случае именованного импорта, для импорта по умолчанию они не нужны.
 
 | Именованный экспорт | Экспорт по умолчанию |
 |--------------|----------------|
@@ -199,9 +199,9 @@ new User('John');
 
 Естественно, может быть только один экспорт "по умолчанию" на файл.
 
-У нас могут быть как экспорт по умолчанию, так и именованные экспорты в одном модуле, но на практике обычно их не смешивают. В модуле есть, либо именованные экспорты, либо экспорт по умолчанию.
+У нас могут быть как экспорт по умолчанию, так и именованные экспорты в одном модуле, но на практике обычно их не смешивают. То есть, в модуле находятся либо именованные экспорты, либо один экспорт по умолчанию.
 
-**Другой момент, что у именованного импорта (естественно) должно быть имя, тогда как `export default` может быть анонимным.**
+**Заметим, что у именованного импорта (естественно) должно быть имя, тогда как `export default` может быть анонимным.**
 
 Например, всё это -- полностью корректные экспорты по умолчанию:
 
@@ -229,7 +229,7 @@ export class { // Ошибка! (необходимо имя, если это н
 
 ### Псевдоним "default"
 
-Слово "default" -- это своего рода "псевдоним" для экспорта по умолчанию, для сценариев, когда нам нужно каким-либо образом сослаться на него.
+Слово "default" -- это своего рода "псевдоним" для экспорта по умолчанию, для экспортирования отдельно от объявления и других ситуаций, когда нам нужно сослаться на него.
 
 Например, если мы уже объявили функцию, то мы можем сделать `export default` вот таким образом:
 
@@ -278,17 +278,17 @@ new User('John');
 
 ### Должен ли я использовать экспорт по умолчанию?
 
-Нужно быть осторожным с использованием экспорта по умолчанию, потому что он поддерживается несколько иначе.
+Нужно быть осторожным с использованием экспорта по умолчанию, потому что он сложнее в поддержке.
 
-Именованные экспорты очевидны. У них есть явное имя для импорта, мы получаем от них эту информацию, и это хорошо.
+Именованные экспорты "включают в себя" своё имя. Эта информация является частью модуля, говорит нам, что именно экспортируется.
 
 Также именованные экспорты вынуждают нас использовать правильное имя при импорте:
 
 ```js
 import {User} from './user.js';
 ```
 
-Для экспорта по умолчанию нам нужно создать своё собственное имя:
+Для экспорта по умолчанию мы можем выбрать любое имя при импорте:
 
 ```js
 import MyUser from './user.js'; // можно импортировать с любым именем, и это будет работать
@@ -307,7 +307,7 @@ import func from '/path/to/func.js';
 
 Другим решением может быть -- использование именованных экспортов везде. Даже, если экспортируется только одна вещь, она всё равно экспортируется с именем, без использования `default`.
 
-Это так же немного упрощает реэкспорт (смотрите ниже).
+Это также немного упрощает реэкспорт (смотрите ниже).
 
 ## Реэкспорт
 
@@ -336,7 +336,7 @@ auth/
     ...
 ```
 
-Мы бы хотели распространить функциональность пакета через единую точку входа, такую, как "главный файл" `auth/index.js`, чтобы можно было использовать таким образом:
+Мы бы хотели сделать функционал нашего пакета доступным через единую точку входа: "главный файл" `auth/index.js`. Чтобы можно было использовать его следующим образом:
 
 ```js
 import {login, logout} from 'auth/index.js'
@@ -359,7 +359,7 @@ export {Github};
 ...
 ```
 
-"Рекэкспорт" -- это просто более короткая запись для этого:
+"Реэкспорт" -- это просто более короткая запись для этого:
 
 ```js
 // 📁 auth/index.js
@@ -376,15 +376,15 @@ export {default as Github} from './providers/github.js';
 ````warn header="Механизм рэкспортирования значения по умолчанию -- запутанный"
 Обратите внимание: `export User from './user.js'` не будет работать. Тут синтаксическая ошибка. Чтобы реэкспортировать экспорт по умолчанию, мы должны явно написать `{default as ...}`, как в примере выше.
 
-Так же есть ещё одна странность: `export * from './user.js'` реэкспортирует только именованные экспорты, исключая экспорты по умолчанию. Ещё раз, мы должны обозначить это явно.
+Так же есть ещё одна странность: `export * from './user.js'` реэкспортирует только именованные экспорты, исключая экспорты по умолчанию. Ещё раз заметим: мы должны обозначить экспорт по умолчанию явно.
 
 Например, чтобы реэкспортировать всё, нам нужны две инструкции:
 ```js
 export * from './module.js'; // для реэкспорта именованных экспортов 
 export {default} from './module.js'; // для реэкспорта по умолчанию
 ```
 
-Экспорт по-умолчанию должен быть обозначен явно только при реэкспорте: `import * as obj` работает нормально. Экспорт по-умолчанию будет находиться в `obj.default`. Так что, здесь есть некоторая асимметрия между конструкциями импорта и экспорта.
+Экспорт по умолчанию должен быть обозначен явно только при реэкспорте: `import * as obj` работает нормально (при этом экспорт по умолчанию будет находиться в `obj.default`). Так что здесь есть некоторая асимметрия между конструкциями импорта и экспорта.
 ````
 
 ## Итого
@@ -404,15 +404,15 @@ export {default} from './module.js'; // для реэкспорта по умо
 
 - Именованные экспорты из модуля:
   - `import {x [as y], ...} from "mod"`
-- Экспорт по-умолчанию:  
+- Экспорт по умолчанию:  
   - `import x from "mod"`
   - `import {default as x} from "mod"`
 - Всё сразу:
   - `import * as obj from "mod"`
-- Только получить/оценить модуль, не импортировать:
+- Только подключить модуль (он запустится), но не присваивать его переменной:
   - `import "mod"`
 
-Мы можем поставить импорт/экспорт инструкции после или перед другим кодом, это не имеет значения.
+Мы можем поставить import/export в начале или в конце скрипта, это не имеет значения.
 
 Так что, технически, это нормально:
 ```js
@@ -423,9 +423,9 @@ import {sayHi} from './say.js'; // импорт в конце файла
 
 На практике импорты, чаще всего, располагаются в начале файла. Но это только для большего удобства.
 
-**Обратите внимание, что инструкции импорт/экспорт не работают внутри `{...}`.**
+**Обратите внимание, что инструкции import/export не работают внутри `{...}`.**
 
-Условный импорт, как этот, работать не будет:
+Условный импорт, такой как ниже, работать не будет:
 ```js
 if (something) {
   import {sayHi} from "./say.js"; // Ошибка: импорт должен быть на верхнем уровне