Apply suggestions from code review

Co-Authored-By: ca11ado <projects.tlt@yandex.ru>

Author: lex111

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

@@ -26,9 +26,9 @@
 ```
 
 ````smart header="Не ставится точка с запятой после экспорта класса/функции"
-Обратите внимание, что `export` перед классом или функцией не делает их [функциональным выражением](info:function-expressions-arrows). Это всё так же объявление функции, хотя и экспортируемое.
+Обратите внимание, что `export` перед классом или функцией не делает их [функциональным выражением](info:function-expressions-arrows). Это всё также объявление функции, хотя и экспортируемое.
 
-Большинство руководств по стилю кода в JavaScript рекомендуют ставить точку с запятой после инструкций, но не после функций или объявлений классов.
+Большинство руководств по стилю кода в JavaScript рекомендуют ставить точку с запятой после инструкций, но не после объявлений функций или классов.
 
 Поэтому в конце `export class` и `export function` не должно быть точки с запятой.
 
@@ -42,9 +42,9 @@ export function sayHi(user) {
 
 ## Экспорт отдельно от объявления
 
-Так же мы можем написать `export` отдельно.
+Также можно написать `export` отдельно.
 
-Здесь, мы сначала объявляем, а затем экспортируем:
+Здесь мы сначала объявляем, а затем экспортируем:
 
 ```js  
 // 📁 say.js
@@ -57,7 +57,7 @@ function sayBye(user) {
 }
 
 *!*
-export {sayHi, sayBye}; // список экспортируемого
+export {sayHi, sayBye}; // список экспортируемых переменных
 */!*
 ```
 
@@ -77,7 +77,7 @@ sayHi('John'); // Hello, John!
 sayBye('John'); // Bye, John!
 ```
 
-Но, если список получается длинным, мы можем импортировать всё, как объект, используя `import * as <obj>`. Например:
+Но если список получается длинным, мы можем импортировать всё в виде объекта, используя `import * as <obj>`. Например:
 
 ```js
 // 📁 main.js
@@ -89,13 +89,13 @@ say.sayHi('John');
 say.sayBye('John');
 ```
 
-На первый взгляд "импортировать всё" выглядит очень удобно, не надо писать лишнего, почему мы вообще явно пишем, что нам нужно экспотировать?
+На первый взгляд "импортировать всё" выглядит очень удобно, не надо писать лишнего, почему мы вообще явно пишем, что нам нужно экспортировать?
 
 Для этого есть несколько причин.
 
 1. Современные инструменты сборки ([webpack](http://webpack.github.io) и другие) собирают модули вместе и оптимизируют их, ускоряя загрузку и удаляя неиспользуемый код.
 
-    Скажем, мы добавили в наш проект стороннюю библиотеку `lib.js` с множеством функций:
+    Предположим, мы добавили в наш проект стороннюю библиотеку `lib.js` с множеством функций:
     ```js
     // 📁 lib.js
     export function sayHi() { ... }
@@ -110,14 +110,14 @@ say.sayBye('John');
     ```
     ...Тогда оптимизатор автоматически определит это и полностью удалит другие функции из собранного кода, тем самым делая код меньше. Это называется "tree-shaking".
 
-2. Явное перечисляя то, что хотим импортировать, мы получаем более короткие имена: `sayHi()`, вместо `lib.sayHi()`.
+2. Явное перечисляя то, что хотим импортировать, мы получаем более короткие имена: `sayHi()` вместо `lib.sayHi()`.
 3. При явных импортах упрощается беглый обзор кода: что и где используется. Это упрощает поддержку и рефакторинг кода.
 
 ## Импорт "как"
 
 Мы так же можем использовать `as`, чтобы импортировать под другими именами.
 
-Например, для краткости, давайте импортируем `sayHi` в локальную переменную `hi` и тоже самое с `sayBye`:
+Например, для краткости, давайте импортируем `sayHi` в локальную переменную `hi`, то же самое сделаем с функцией `sayBye`:
 
 ```js
 // 📁 main.js
@@ -151,13 +151,13 @@ say.hi('John'); // Hello, John!
 say.bye('John'); // Bye, John!
 ```
 
-## Экспортирование по-умолчанию
+## Экспортирование по умолчанию
 
 До сих поры мы видели, как экспортировать/импортировать вещи, опционально под другими именами.
 
 На практике модули могут содержать:
 - Либо библиотеку, набор функций, как `lib.js`.
-- Либо сущьность, как `class User`, описанный в `user.js`. Во всём модуле есть только этот класс.
+- Либо сущность, например `class User`, определенную в `user.js`. Во всём модуле есть только этот класс.
 
 По большей части, предпочтителен второй подход, чтобы каждая "вещь" находилась в своём собственном модуле.
 
@@ -190,20 +190,20 @@ import *!*User*/!* from './user.js'; // не {User}, просто User
 new User('John');
 ```
 
-Импорты без фигурных скобок выглядят лучше. Обычная ошибка для начинающих использовать модули: забыть про фигурные скобки совсем. Так что, помните, фигурные скобки необходимы только в случае именнованного импорта, для импорта по-умолчанию они не нужны.
+Импорты без фигурных скобок выглядят лучше. Обычная ошибка для начинающих использовать модули: забыть про фигурные скобки совсем. Так что, помните, фигурные скобки необходимы только в случае именованного импорта, для импорта по-умолчанию они не нужны.
 
-| Именованный экспорт | Экспорт по-умолчанию |
+| Именованный экспорт | Экспорт по умолчанию |
 |--------------|----------------|
 | `export class User {...}` | `export default class User {...}` |
 | `import {User} from ...` | `import User from ...`|
 
-Естественно, может быть только один экспорт "по-умолчанию" на файл.
+Естественно, может быть только один экспорт "по умолчанию" на файл.
 
-У нас могут быть, и экспорт по-умолчанию, и именованные экспорты в одном модуле, но на практике люди обычно их не смешивают. В модуле есть, либо именованные экспорты, либо экспорт по-умолчанию.
+У нас могут быть как экспорт по умолчанию, так и именованные экспорты в одном модуле, но на практике обычно их не смешивают. В модуле есть, либо именованные экспорты, либо экспорт по умолчанию.
 
 **Другой момент, что у именованного импорта (естественно) должно быть имя, тогда как `export default` может быть анонимным.**
 
-Например, всё это -- полностью валидные экспорты по-умолчанию:
+Например, всё это -- полностью корректные экспорты по умолчанию:
 
 ```js
 export default class { // у класса нет имени
@@ -222,14 +222,14 @@ export default ['Jan', 'Feb', 'Mar','Apr', 'Aug', 'Sep', 'Oct', 'Nov', 'Dec'];
  В противоположность этому, отсутствие имени у именованных импортов приведёт к ошибке:
 
 ```js
-export class { // Ошибка! (необходимо имя, если это не экспорт по-умолчанию)
+export class { // Ошибка! (необходимо имя, если это не экспорт по умолчанию)
   constructor() {}
 }
 ```     
 
 ### Псевдоним "default"
 
-Слово "default" -- это своего рода "псевдоним" для экспорта по-умолчанию, для сценариев, когда нам нужно каким-либо образом сослаться на него.
+Слово "default" -- это своего рода "псевдоним" для экспорта по умолчанию, для сценариев, когда нам нужно каким-либо образом сослаться на него.
 
 Например, если мы уже объявили функцию, то мы можем сделать `export default` вот таким образом:
 
@@ -238,10 +238,10 @@ function sayHi(user) {
   alert(`Hello, ${user}!`);
 }
 
-export {sayHi as default}; // тоже самое, как, если бы мы добавили "export default" перед функцией
+export {sayHi as default}; // то же самое, как если бы мы добавили "export default" перед функцией
 ```
 
-Или, давайте представим: модуль `user.js` экспортирует одну вещь "по-умолчанию" и несколько именованных (редкий, но возможный случай):
+Или давайте представим следующее: модуль `user.js` экспортирует одну сущность "по умолчанию" и несколько именованных (редкий, но возможный случай):
 
 ```js
 // 📁 user.js
@@ -256,7 +256,7 @@ export function sayHi(user) {
 }
 ```
 
-Мы можем импортировать экспорт по-умолчанию вместе с именованными экспортами таким образом:
+Мы можем импортировать экспорт по умолчанию вместе с именованными экспортами таким образом:
 
 ```js
 // 📁 main.js
@@ -265,7 +265,7 @@ import {*!*default as User*/!*, sayHi} from './user.js';
 new User('John');
 ```
 
-Или, если мы импортируем всё, как объект (`*`), тогда свойство `default` -- это и есть экспорт по-умолчанию:
+Или если мы импортируем всё как объект (`*`), тогда свойство `default` -- это и есть экспорт по умолчанию:
 
 ```js
 // 📁 main.js
@@ -276,27 +276,27 @@ new User('John');
 ```
 
 
-### Должен ли я использовать экспорт по-умолчанию?
+### Должен ли я использовать экспорт по умолчанию?
 
-Нужно быть осторожным с использованием экспорта по-умолчанию, потому что он поддерживается несколько иначе.
+Нужно быть осторожным с использованием экспорта по умолчанию, потому что он поддерживается несколько иначе.
 
 Именованные экспорты очевидны. У них есть явное имя для импорта, мы получаем от них эту информацию, и это хорошо.
 
-Так же, именованные экспорты вынуждают нас использовать правильное имя при импорте:
+Также именованные экспорты вынуждают нас использовать правильное имя при импорте:
 
 ```js
 import {User} from './user.js';
 ```
 
-Для экспорта по-умолчанию, нам нужно создать своё собственное имя:
+Для экспорта по умолчанию нам нужно создать своё собственное имя:
 
 ```js
 import MyUser from './user.js'; // можно импортировать с любым именем, и это будет работать
 ```
 
 Так что, тут мы получаем немного больше свободы, которая может привести к злоупотреблениям, члены команды могут использовать разные имена для одной и той же вещи.
 
-Обычно, чтобы избежать этого и соблюсти консистентность кода, есть правило: имена импортируемых переменных должны соответствовать именам файлов. Вот так:
+Обычно, чтобы избежать этого и соблюсти единообразие кода, есть правило: имена импортируемых переменных должны соответствовать именам файлов. Вот так:
 
 ```js
 import User from './user.js';
@@ -311,7 +311,7 @@ import func from '/path/to/func.js';
 
 ## Реэкспорт
 
-"Реэкспорт" синтаксис `export ... from ... ` позволяет импортировать что-нибудь и тут же экспортировать это (возможно под другим именем), например, вот так:
+Синтаксис "реэкспорта" `export ... from ... ` позволяет импортировать что-нибудь и тут же экспортировать это (возможно под другим именем), например, вот так:
 
 ```js
 export {sayHi} from './say.js';
@@ -373,15 +373,15 @@ export {default as Github} from './providers/github.js';
 ...
 ```
 
-````warn header="Механизм рэкспортирования значения по-умолчанию -- запутанный"
-Обратите внимание: `export User from './user.js'` не будет работать. Тут синтаксическая ошибка. Чтобы реэкспортировать экспорт по-умолчанию, мы должны явно написать `{default as ...}`, как в примере выше.
+````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'; // для реэкспорта по-умолчанию
+export {default} from './module.js'; // для реэкспорта по умолчанию
 ```
 
 Экспорт по-умолчанию должен быть обозначен явно только при реэкспорте: `import * as obj` работает нормально. Экспорт по-умолчанию будет находиться в `obj.default`. Так что, здесь есть некоторая асимметрия между конструкциями импорта и экспорта.
@@ -428,7 +428,7 @@ import {sayHi} from './say.js'; // импорт в конце файла
 Условный импорт, как этот, работать не будет:
 ```js
 if (something) {
-  import {sayHi} from "./say.js"; // Ошибка: импорт должнен быть на верхнем уровне
+  import {sayHi} from "./say.js"; // Ошибка: импорт должен быть на верхнем уровне
 }
 ```