Строгий режим JavaScript

TL;DR

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

Как фронтенд-разработчик, который кодирует на JavaScript или его расширенном наборе, TypeScript, я иногда испытываю неуверенность, имея дело с граничным сценарием или сравнивая значение из API-интерфейса серверной части и атрибута DOM. Так что да, именно поэтому я наткнулся на книгу Effective JavaScript, написанную Дэвидом Херманом. Эта книга содержит 68 примеров на JavaScript, включая переменные, функции, объекты, прототипы, параллелизм и т. д.

И сегодня я подытожу то, что узнаю из темы 1 книги.

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

Вот основные сведения о строгом режиме, которые вам могут понадобиться.

Помимо преимуществ, которые дает нам строгий режим, нам по-прежнему нужно осторожно выбирать, нужно ли нам использовать строгий режим и как мы будем использовать строгий режим. Вот несколько примеров из книги.

Во-первых, строгий режим должен быть написан в начале скрипта или функции, если разработчики поместят оператор «строгий режим» в середине функции, это не сработает. Из-за этого, независимо от того, как вы комбинируете функцию или скрипт вместе, вам нужно, чтобы «строгий режим» находился в верхней части скрипта или функции. Однако также есть вероятность, что вам нужно работать с какой-то библиотекой или скриптом, который не должен работать в среде «строгого режима». И это очень опасно, если вы просто объедините скрипт в «строгом режиме» и «не строгом режиме» вместе. Итак, как мы этого достигаем? В Effective JavaScript Дэвид приводит пример использования JavaScript IIFE, немедленно вызываемого функционального выражения, чтобы поместить их в другую область. (Пример ниже не совсем совпадает с примером из книги.)
т.е.

\\\ Content from file1.js
(function(){
  
  'strict mode'
  function a(){
    ...
  }
})()
\\\ Content from file2.js
(function(){
  
  function b(){
    ...
  }
})()

Таким образом, независимо от того, как вы комбинируете файлы file1.js и file2.js, они будут в нужном им режиме. U может спросить, а что противоположный пример? В приведенном ниже файле file1.js используется строгий режим, а ожидается, что file2.js будет работать в обычном JavaScript. Тогда, если мы просто объединим их последовательно, мы столкнемся с проблемами.

\\\ Content from file1.js
'strict mode'
function a(){
  ...
}
\\\ Content from file2.js
function b(){
  const arguments = []; \\ Error, the name 'arguments' is a preserved variable which can't be assigned in strict mode.
}

Кроме того, если мы изменим порядок, «строгий режим» не будет выполняться, потому что оператор «строгий режим» находится в середине скрипта.

\\\ Content from file2.js
function b(){
  const arguments = []; 
}
\\\ Content from file1.js
'strict mode'
\\ Function a is not in strict mode anymore, cuz the above statement 'strict mode' won't be executed.
function a(){
  ...
}

На данный момент вы можете видеть, что строгий режим может вызывать либо весь скрипт, либо отдельные функции, и что не упоминается в моих статьях, так это напротив, он не применяется к блочным операторам в фигурных скобках {}.

Это несколько советов по поводу строгого режима. Пока вы копаетесь в библиотеках, написанных на JavaScript, вы можете заметить, что это утверждение используется часто, и я надеюсь, что теперь вы лучше понимаете, как разработчики работают со «строгим режимом».

Если вам интересно то, что я написал, пожалуйста, следите за обновлениями! В будущем я буду постоянно записывать вещи, которые меня поразили и заслуживают того, чтобы вы потратили 3 минуты на чтение!

Скрестить пальцы!