Область действия и замыкания

Наверное, одна из самых фундаментальных вещей, которые понадобятся вам, чтобы быстрее подобраться к этим терминам — это понимание как именно создание области действия переменных на самом деле работает в JavaScript. Недостаточно иметь анекдотичные расплывчатые представления об области действия.

Книга Область действия и замыкания начинается с развенчания общего ложного представления, что JS — "интерпретируемый язык", и потому он не компилируется. А вот и нет!

Движок JS компилирует ваш код прямо перед выполнением (а иногда и во время выполнения!). Поэтому мы пойдем путем более глубокого понимания подхода компилятора к вашему коду, чтобы понять, как он находит и разбирается с объявлениями переменных и функций. Попутно мы посмотрим типичную схему JS по управлению областью действия переменных, "Всплытие (hoisting)".

Именно это критическое понимание "лексической области действия" является тем, на чем мы потом будем основывать наше исследование замыкания в последней главе этой книги. Замыкание — возможно, единственное самое важное понятие во всем JS, но если вы сперва не разберетесь плотно с механизмом области действия, то замыкание скорее всего останется вне вашего понимания.

Одно важное применение замыкания — это модульный шаблон, который мы уже кратко представили в этой книге в главе 2. Модульный шаблон, возможно, самый преобладающий шаблон организации кода во всем JavaScript; его глубокое понимание должно быть одним из самых высоких ваших приоритетов.

This и прототипы объектов

Пожалуй, одним из самых распространенных и устойчивых ложных фактов о JavaScript является то, что ключевое слово this указывает на функцию, в которой оно появляется. Ужасное заблуждение!

Ключевое слово this динамически привязывается, основываясь на том, как выполняется функция; выясняется, что есть четыре простых правила, помогающих понять и полностью определить привязку this.

Тесно связан с ключевым словом this механизм прототипов объектов, который является цепочкой поисков свойств, похожей на то, как обнаруживаются переменные в лексической области действия. Но обертка прототипов хранит другой большой промах с JS: идея эмуляции (замены) классов и так называемое наследование через прототипы.

К сожалению, желание привнести мышление классами и наследованием в JavaScript — это просто наихудшая вещь, которую вы могли бы сделать; несмотря на то, что синтаксис может вводить вас в заблуждение, будто есть что-то подобное классам, в действительности механизм прототипов фундаментально противоположен по своему поведению.

Что является предметом спора, так это то, лучше ли проигнорировать несоответствие и притвориться, что вы реализуете "наследование", либо все-таки, что является более подходящим, изучить и принять то, как на самом деле работает система прототипов объектов. Последнее подходяще именуется "делегированием поведения".

Это больше, чем синтаксическое предпочтение. Делегирование — это совершенно другой и более мощный шаблон проектирования, который сам по себе заменяет необходимость проектировать классы и их наследование. Но эти утверждения полностью противоречат почти каждому второму посту в блогах, книгам и конференциям по этой теме на всем протяжении существования JavaScript.

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

Но объяснение необходимости рассматриваемых прототипов и делегирования гораздо более запутанно, чем то, которое я тут представил. Если вы готовы переосмыслить всё, что, как вы думаете, вы знаете о "классах" и "наследовании" в JavaScript, то я даю вам шанс "принять красную таблетку" (Матрица, 1999) и проверить главы 4-6 книги this & прототипы объектов этой серии.

Типы и синтаксис

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

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

Но действительно ли приведение — такое сбивающее с толку, такое плохое, такое коварное, что ваш код обречен с самого начала, если вы будете использовать его?

Я отвечаю — нет. После постепенного построения понимания того, как на самом деле работают типы и значения, в главах 1-3, глава 4 берет на себя этот спор и полностью объясняет, как работает приведение типов со всеми его нюансами. Мы увидим, какие нюансы приведения действительно удивляют, а какие нюансы на самом деле имеют смысл, при должном их изучении.

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

Хотите ли вы просто продолжать следовать тому, что говорит большинство, или не желаете принимать в расчет все допущения и хотите взглянуть на приведение свежим взглядом? Книга Типы и синтаксис этой серии заставит вас задуматься.