Comments 67
Например, тут будет ошибка ReferenceError: can't access lexical declaration `app' before initialization:
let app = app || {};
Поэтому все «let не всплывает» и «const не иммутабельный» должны сопровождаться указанием на то, что нужно использовать настоящий ES6. В остальных случаях никаких гарантий как бы и нет.
И честно гвооря не встречал еще сайтов на «чистом» ES6. Правда и не искал.
По поводу комментария выше. Да, действительно, я этого не учел, признаю. Babel довольно сносно обрабатывает подобные ситуации.
Например у меня в магазине IE < 11 это почти 3%. А с 11-м больше 5%.
Немного конечно, но такие пользователи частенько выносят могз, если у них что-то не работает. Поэтому если можно относительно безболезненно их учесть — почему бы и нет.
особенно в виде es5 кода по сравнению с var?
очевидно в es5 let/const транслируется в var всегда
Очевидно, при трансляции добавляется еще и замыкание. Именно поэтому беспокоятся за скорость работы.
Беспокоится не о чем, несолько дополнительных скоупов на скорость ресолвинга var переменной не особенно повлияют (hoisting). О скорости следует думать в более глабольшом машстабе, на этапе дизайна системы и имплементации логики.
for (let i = 0; i<10; i++)
setTimeout(() => console.log(i), 100*i);
Покажите, как этот код может быть написан на es5 без дополнительного замыкания.
Речь была о том что Бабель будет вставлять замыкания на каждый let/const, там где их раньше не было, что не верно.
Менять число аргументов, передаваемых в setTimeout — нельзя, потому что вы — компилятор. И не можете доказать, что setTimeout — это та самая функция из стандартной библиотеки.
PS в Chrome ваш код не будет работать. Первый аргумент должен быть console.log.bind(console)
Так что в общем случае в виде es5 кода — разницы нет.
const не нравиться потому что при доработке уже написанного с ним кода нужно постоянно следить не пора ли какой-то let переделать в const, если не следить, объявления получаются неконсистентными. Отвлекает, а какого-то профита я так и не заметил. Наверно можно какой-нибудь линтер настроить, что бы он находил такие let-ы, но не видя профита я решил не заморачиваться и использовать везде let.
prefer-const
Ну мне видимо уже не нужно)) По сути профит const в том, что не получится написать if (a = b)
вместо if (a == b)
, но вот такого как раз и не случается, так как любой линтер такое с пелёнок проверять умеет.
Так в чём сила const, если единственная причина его существования ломается о любой линтер? При этом есть минимум два минуса, один из которых я привёл выше (prefer-const решает его лишь частично).
Единственное различие между const и let в том, что const обещает — переприсвоения не произойдёт.
С учётом вышеизложенного, const делает код более читаемым.
То есть назначениеconst
в том, чтобы дать человеку, читающему код, сигнал, что переменная переприсвоена не будет. Аlet
, соответственно, сигнализирует о том, что переменная скорее всего будет переприсвоена, соответственно это что-то вроде счётчика или флага, который далее будет проверен, то есть нужно обратить на это внимание.
А если вы используете иммутабельные структуры, где изменение данных всегда означает изменение ссылки на объект, то вместе с const
получаете гарантию полной неизменяемости, и по ссылке, и по значению.
при доработке уже написанного с ним кода
Про то и речь, что везде const, только где надо let, и вот при дороботке кода один из let становиться неизменяемым и это вообще никак не видно, код продолжает отлично работать. Если не следить за этим, то получаем неконсистентные объявления, что меня как перфекциониста напрягает, если следить вручную, то на это уходит уже значимое время, вроде бы немного, но везде помаленьку и начинает реально напрягать постоянно на это отвлекаться. Если настроить prefer-const, как посоветовали выше, скорей всего будет заметно лучше, изредка прийдётся править замечания линтера и постоянно писать на два символа больше. Мелочи, но и плюсы тоже совсем незначительны. Для меня минусы перевесили, да и вообще, складывается впечатление, что большинство использует const не ради каких-то реально видимых для себя плюсов, а просто потому что это сейчас модно.
const позволяет вам создавать «read-only» переменные, по моему опыту ~80% всех объявляемых переменных никогда не меняются и по сути являются константами.
Это уже другой подход, отличный от
нужно изначально писать везде толькоconst
, и по мере надобности добавлятьlet
его я не пробовал, но могу предположить, что постоянно задумываться будет ли переменная меняться мне нафик не надо, особенно если это не приносит мне какой-то пользы.
Большой комментарий чуть ниже тоже вам))
Изначальная запись всего в `const` — «набивает руку» везде его использовать.
В моем первом комментарии не говорилось о том что const нужно везде писать бездумно, думать нужно всегда.
думать нужно всегда
вопрос о чём думать и какую пользу это приносит, если у вас проекты той сложности, когда не хватает о чём думать и в новых возможностях языка вы ищите проблемы а не решения, то да const вам необходим. Мне же нужно меньше думать о всяком бесполезном и больше делать, const тут явно в минус.
Только в случае неиспользуемых переменных от этого нельзя совсем избавиться, а в случае с const можно.
Вот вы все тут набрасываете на мои аргументы против const, но никто толком не говорит зачем он ему пригодился? Единственный аргумент сразу не ломающийся о какой-нибудь линтер или ещё что-то привёл swandir :
С учётом вышеизложенного, const делает код более читаемым.
То есть назначение const в том, чтобы дать человеку, читающему код, сигнал, что переменная переприсвоена не будет. А let, соответственно, сигнализирует о том, что переменная скорее всего будет переприсвоена, соответственно это что-то вроде счётчика или флага, который далее будет проверен, то есть нужно обратить на это внимание.
Но вот кто-то из вас пробовал проверить как это работает на практике? Я вот пробовал, именно этот аргумент ещё с год назад показался мне достаточно убедительным чтобы попробовать. И знаете как он работает? Вообще никак! Вот открываю я чуть ранее (не знаю, может надо было дольше ждать) написанный мною код с const, вижу переменную объявленную через const, ура, теперь я знаю, что она не будет меняться, но что мне это даёт? Зачем мне это знать? Это как-то помогает понять логику далее написанного кода? Я этого вообще не заметил, скорее наоборот, это абсолютно лишняя инфа, отвлекающая от сути. Приведите конкретный пример кода и давайте обсудим как программист читая его лучше понимает его суть за счёт использования в нём const? Это реально будет лучшим доказательством его полезности. Я пробовал иначе, взял готовый код написанный ещё на var-ах и начал переписывать его на const+let, я думал, что может используя const я найду какие-то хитрые баги, которые раньше не замечал и которые const автоматом пресекает. Но и этого не произошло. Все теоретические плюсы const которые можно найти в Интернете на практике либо не работают, либо вообще идут в минус. Мне намного интереснее было бы услышать в качестве аргументов за const не эту теоретическую копипасту с Интернета, а чей-то практический опыт, пусть и субъективный, что-то типа: чувак, вот я начал писать с const и я реально ощутил, что мне стало проще перечитывать свой ранее написанный код. Вот вы можете так сказать?
Кстати ещё один минус const вспомнил:
let a;
let b;
let c;
let d;
намного красивей чем:
const a;
let b;
const c;
let d;
Если же группировать несколько переменных в один const/let, то ещё хуже получается, приходиться либо постоянно разрывать группу, либо делать две группы и раскидывать переменные по ним, что приводит к тому, что две переменные, которые близки по сути и должны объявляться рядышком, оказываются далеко друг от друга.
Это мелочь конечно, но таких мелочей на практике вылазит довольно много, я просто довно всё это пробовал и сейчас постепенно по ходу разговора вспоминаю как это было.
Часто наблюдаю вот такую конструкцию в начале какого-нибудь метода в чужих файлах:
var $this = $(this),
$container = $this.closest(".container"),
$button = $container.find(".button")
Здесь замена var
на const
напрашивается.
Ну ок, так всё таки, что это даст в сравнении с бездумным let везде? Зачем мне лишний раз задумываться выбирая const или let?
А думать и не надо. При написании подобного "пролога" с серией операций поиска по DOM надо просто всегда писать const.
Здесь действительно почти не надо, но лишний тик в голове всё же иногда происходит, есть более сложные случаи. Процитирую себя:
Приведите конкретный пример кода и давайте обсудим как программист читая его лучше понимает его суть за счёт использования в нём const?
Как знание о том, что $this не будет меняться помогает вам понять логику дальнейшего кода? И если этого не происходит, то нахрена спрашивается вы в него вцепились? Модно, ES6 и всё такое?
Как знание о том, что $this не будет меняться помогает вам понять логику дальнейшего кода? И если этого не происходит, то нахрена спрашивается вы в него вцепились? Модно, ES6 и всё такое?
Очень просто. Если в коде будет ошибка и я буду ее искать — мне не придется проверять гипотезу "а может, какой-то баран (возможно, даже я сам) изменил $this посреди метода"?
но никто толком не говорит зачем он ему пригодился
А зачем вообще нужны иммутабельные значения в программировании?
Вон Riim с хабра никогда их не использует и вроде все норм, код даже красивее выглядит, ровнее…
Если серьезно, то вот вам пример — я считываю какое-то значение из конфига, мне нужно чтобы оно не менялось внутри данного скоупа (в том числе чтобы те кто будет работать с этим кодом после меня не могли его изменить)
const currentState = config.currentState
// теперь currentState гарантировано не может быть изменено.
то вот вам пример
да, чуть выше я признал это плюсом в некоторых ситуациях, а именно в командах состоящих из "какой-то баран". Может вам уже пора поговорить с ним, а то я смотрю он вам всем всю малину портит))
Вон Riim с хабра никогда их не использует и вроде все норм, код даже красивее выглядит, ровнее…
обажаю хабр, здесь всегда найдётся чудо которое в ситуации где можно спокойно сказать "да чувак, в твоих аргументах что-то есть и твой вариант похоже имеет право на жизнь" и на этом спокойно разойтись, будет до хрипоты в голосе усираться и доказывать, что нет!, только его вариант единственно правильный и никак иначе. А когда кончаться аргументы скатится на банальное язвление. Язвить я умею не хуже вашего, поэтому если больше нет интересных аргументов, то предлагаю не трахать друг другу мозг и на этом разойтись.
С опытом понимание само придет.
я признал это плюсом в некоторых ситуациях, а именно в командах состоящих из "какой-то баран"
Команда всегда состоит из «какой-то баран», даже если программист там один. Потому что программисты — люди, а люди делают ошибки.
И использование const
— лишний способ избежать ошибок.
Команда всегда состоит из «какой-то баран»
у вас видимо всегда, ну ок, свои аргументы я привёл, с этим плюсом const тоже согласен, кому интересно почитают, взвесят и решат для себя (а ещё лучше попробуют). Что-то новое здесь уже вряд ли прозвучит, а препираться с теми кто принципиально не готов признавать альтернативы смысла нет, так что всем удачи.
Статья озаглавлена «ES6 const это не про иммутабельность» и в ней как раз таки рассказывается как работает 'иммутабельност' для const в ES6
То что иммутабелность не поддерживается для содержания объектов — так это часть стандарта и везде на это и так указано.
Мне кажется контент такого содержания больше подходит для tweet'a или каких-то микро-блогов.
Какое-то непонимание «про что» const в JS может возникнуть в двух случаях:
1) непонимание чем отличаются константы, переменные и иммутабельные переменные вообще в программировании
2) незнание синтаксиса JS, предположение, что const — объявление константы, а не иммутабельной переменной
ES6 const это не про иммутабельность