Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 26

НЛО прилетело и опубликовало эту надпись здесь
Очень странное решение, ибо так вы отдаёте всё наружу, не разделяя на публичное и приватное
Всего голосов 5: ↑5 и ↓0+5
НЛО прилетело и опубликовало эту надпись здесь
лучше бы разработчики node.js сделали всё открытое, а кому уже нужно закрывать, те бы писали private перед переменными.

так уже было изначально в браузерах, когда функция, объявленная в одном тэге script была доступна в другом. Такой подход оказался очень неудобным, и разработчикам пришлось изощряться, чтобы создать себе приватную область видимости. Полностью эта история рассказана в этой статье.


Поэтому текущий модульный подход с необходимостью писать явный export оказывается лучше и удобнее для большинства разработчиков. Мы изначально высвечиваем из модуля его публичное API, а потом уже модифицируем его внутри как хотим, и нам не нужно писать private каждый раз, когда мы рефакторим и создаем внутри новые функции и переменные.

Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
Ваше предложение сделать все открытым для импорта по умолчанию страдает от той же проблемы, что и до-модульный Javascript с глобальной областью видимости. Очень легко ошибиться и нечаянно оставить открытыми функции, которые не предназначались для использования снаружи.

Именно поэтому, на опыте прошлых ошибок, JS-модули сделаны с явным экспортом, чтобы не было случайных утечек приватных функций
Всего голосов 1: ↑1 и ↓0+1
оставить открытыми функции, которые не предназначались для использования снаружи.

Это мелочи. Гораздо хуже то, что засоряется глобальное пространство имён. Приходится вводить префиксы, чтобы модули не конфликтовали.
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
я должен писать список ещё и при экспортировании.

А я ещё и комментарий пишу с рекомендуемым способом импортирования этого модуля.
Потому что это удобнее, чем каждый раз вспоминать, что и под какими именами из него импортируется.
Комментарий пока не оценивали0
Public Morozov, теперь и на JS
Всего голосов 29: ↑29 и ↓0+29
[a-zA-Zа-яА-ЯёЁ_0-9] — имена перемеренных, констант, классов кириллицей?
Всего голосов 3: ↑3 и ↓0+3
Emoji и другие алфавиты не учтены.
Всего голосов 1: ↑1 и ↓0+1
Вот вы ржоте, а у нас некоторые клиенты хотят эмоджи во всяких странных и не предназначенных для этого местах :(
Комментарий пока не оценивали0
Еще перепишите автозамену let на const и сразу в продакшен заливайте, только заранее найдите новое место работы.
Всего голосов 10: ↑10 и ↓0+10
Зачем же перед каждой переменной и функцией писать export, если можно это сделать в конце файла?:

export {
  name1,
  name2,
  ...
}

Всего голосов 3: ↑3 и ↓0+3
НЛО прилетело и опубликовало эту надпись здесь
Меня очень бесит, что перед каждой переменной и функцией в модулях нужно писать слово export.

И правильно бесит, потому что не нужно так делать.

Всего голосов 4: ↑4 и ↓0+4
Экспериментально эта возможность была доступна с Node 8.0 с 0 фазы. Текущий релиз — это большой шаг в этом направлении

Неплохо было бы раскрыть, что именно произошло здесь. Попробую это сделать.


8 версия содержала в себе старую версию реализации. У этой реализации были недостатки, поэтому было решено переделать ее. Текущая версия является обладает новыми возможностями, например доступом к классическому require() из es-модуля.


Кроме этого, новая реализация позволяет использовать расширение .js для es-модулей (вместо специального .mjs), предлагая использовать поле "type": "module" в package.json, чтобы авторы npm-модулей могли сами определять, является ли их пакет es-модулями, или старыми commonjs

Всего голосов 3: ↑3 и ↓0+3
Эх почему не `private` вместо `#`?
Всего голосов 6: ↑6 и ↓0+6
НЛО прилетело и опубликовало эту надпись здесь
Неужели это нельзя было зашить в интерпритатор? Пусть хоть там в ___x преодбразует какая разница. Просто язык превращается в набор символов, который нужно запоминать, а к реальности никакого отношения.
Всего голосов 2: ↑2 и ↓0+2
НЛО прилетело и опубликовало эту надпись здесь
С обратной совместимостью скорее никак, скорее тут надо вводить новое ключевое слово private как const, static на уровне интерпретатора.
Комментарий пока не оценивали0

Ответ на этот вопрос есть в официальном FAQ. Ещё вот тут в комментариях на Хабре эту тему поднимали.


А если совсем коротко, то не так уж просто добавить полноценный private keyword в динамический язык с 20-летней историей

Всего голосов 1: ↑1 и ↓0+1
Меня интересует, как обстоит с этим дело в TypeScript?
На данный момент, насколько я понимаю, не весь JS-код будет валидным для TS?
Комментарий пока не оценивали0
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время
Разблокировать темную тему

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr