Открыть список
Как стать автором
Обновить

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

Аж глаза заболели от повсеместного let
Чтобы глаза привыкли к let, надо сначала закрыть их, досчитать до десяти, и плавно открывать.
Ну а вообще, 2019 годе, же, ну.
2019 год же, const
На два символа больше. Так много печатать лень =)
НЛО прилетело и опубликовало эту надпись здесь

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

¯\(ツ)


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

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

function isTouchDevice() {
  try {
    document.createEvent('TouchEvent');
    return true;
  }
  catch {
    return false;
  }
}
Не очень понятно, зачем бы на практике так часто уплощать массив, чтобы потребовались специальные методы.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
ruvds.com
Численность
11–30 человек
Дата регистрации
Представитель
ruvds

Блог на Хабре