Примеры использования некоторых новых возможностей JavaScript

[pterodaktil]

Аж глаза заболели от повсеместного let

[belkin_ai]

Чтобы глаза привыкли к let, надо сначала закрыть их, досчитать до десяти, и плавно открывать.
Ну а вообще, 2019 годе, же, ну.

[pterodaktil]

2019 год же, const

[Tenebrius]

На два символа больше. Так много печатать лень =)

[justboris]

А вы точно полиция? У вас никнейм отклеился

[mayorovp]

Глядя на примеры с toString можно подумать, что раньше оно весь код в одну строку выводило, а теперь разбивает по строкам.

Хотя на самом деле, раньше оно теряло выравнивание, а теперь не теряет.

[Keyten]

trimStart / trimEnd ведут к очевидным проблемам с rtl текстом: ведь как начало, так и конец строки находятся наоборот, и кто-то может ожидать, что trimStart на арабском тексте удалит пробелы справа.

[mayorovp]

Так ведь оно и правда удаляет пробелы справа… Собственно, потому от названий trimLeft/trimRight и отказались.

[Keyten]

Хм, ну я попробовал (перед тем как написать комментарий), и у меня удалились слева. Окей, тогда всё верно.

[mayorovp]

Скорее всего, пробелы удалились где положено (справа), но вы этого не поняли, потому что ваш текстовый редактор / консоль интерпретатора был в ltr режиме.

[karantir]

Продолжается портирование underscore в стандартную библиотеку. Логично.

[aleksandy]

Если объект исключения не используется в блоке catch

То это плохой код.

Исключение либо надо как-то обрабатывать, хотя бы в тот же лог записать, либо вообще не ловить.

[mayorovp]

Если это feature detect — то не нужно. Если исключение было при попытке записать что-то в лог — то его тоже в лог записывать не нужно.

[aleksandy]

1. А можно пример подобного feature detect? Я что-то не представляю, как по факту наличия какого-то (неизвестного!!!) исключения можно сделать вывод, о доступности/недоступности чего-либо.
2. Как часто Вы заворачиваете console.log() в try-блок?

[mayorovp]

let templateEngine;

try {
    eval("true");
    templateEngine = jitTemplateEngine;
} catch {
    templateEngine = interpreterTemplateEngine;
}

[justboris]

По-хорошему, в catch-блоке надо проверить тип ошибки, и выбросить ее дальше если он неправильный. Сэкономит потом время на отлов багов в этом месте

[mayorovp]

Но тут есть два вопроса:

1. Какой тип ошибки предполагается увидеть? В стандарте не указывается какое исключение кидает eval будучи запрещённой через CSP!

   
   

2. Какое ещё исключение в принципе возможно в этом блоке? От чего предполагается защищаться?

   
   

[justboris]

Хотя бы проверять, что это был EvalError, а не какой-то еще. Можно получить ReferenceError: jitTemplateEngine is not defined, если где-нибудь в имени переменной опечататься.

[mayorovp]

Так как вы надёжно отличите EvalError от какого-то ещё, если стандарт не указывает какоё именно исключение выбрасывать?

[justboris]

¯\(ツ)/¯

возможно, с eval проверять нечего. Но вот, в варианте внизу с TouchEvent есть что, например. В общем, вариантов, где ошибку можно оставить без проверки, не так уж и много, чтобы опциональный аргумент был сколько-нибудь полезным.

[noodles]

1. А можно пример подобного feature detect? Я что-то не представляю, как по факту наличия какого-то (неизвестного!!!) исключения можно сделать вывод, о доступности/недоступности чего-либо.

function isTouchDevice() {
  try {
    document.createEvent('TouchEvent');
    return true;
  }
  catch {
    return false;
  }
}

[torbasow]

Не очень понятно, зачем бы на практике так часто уплощать массив, чтобы потребовались специальные методы.