Pull to refresh

Comments 32

Вы забыли упомянуть одну важную деталь: Не нужно использовать это в реальных проектах :)

Такое «магическое» поведение может зависеть от браузера, может поменяться внезапно в каком-то браузере или еще чего.

да нет здесь никакой магии, конструктор принимает число, а NaN — число
приведение типов также работает предсказуемо и ожиданно
в исходниках momentjs используют подобную конструкцию


статья лишь напоминает, переходящим с php и других языков, с чуть другой логикой, что в javascript есть особые числа — Infinity, NaN и методы для работы с числами isFinite(), isNaN()

UFO just landed and posted this here

Тяжела и неказиста жизнь JavaScript-ера… Каждый, не читавший спеку, думает, что он умнее, потому что "в большинстве языков" спека другая.

UFO just landed and posted this here
Это не магия. NaN в JS это данность, Date работает так как работает. Никаких изменений тут не будет. Даже в черновиках следующих версий JS ничего про дату нет, хотя очень очень хочется добавить установку произвольной таймзоны. Нет и не будет.
Как и упомянул выше ua9msn изменений поведения типа Date не предвидется. По указанной Вами ссылке говорится о исправлении API в его использовании за счёт введения в язык новых типов — CivilDate, CivilTime etc.
Или я что-то упустил?
UFO just landed and posted this here
UFO just landed and posted this here
Все же я так и не понял полезность данной конструкции в реальной жизни и чем полезен NaN

Например, проверить или распарсенная строка действительно была датой.


let date = new Date('foo');
let isInvalidDate= isNaN(date);
console.log(isInvalidDate ? "Yes, it was invalid" : "Ooops, was OK");
Только NaN тут не при чём, на самом деле. Это функция isNaN выдаёт true на всё, что не приводится к числу, в частности, на строку «Invalid Date». А Number.isNaN(«Invalid Date»)===false.
Изложение в статье крайне сумбурное и запутывает простые вещи.
Я задам возможно неправильный вопрос — но если Вы принимаете ко вниманию ситуации, когда Вам необходимо создавать даты с вероятно невалидными данными, возможно стоит все-таки изначально делать соответствующие проверки? Мне кажется это будет более правильная логика чем работать далее с Invalid Date…
Ситуация возникает когда необходимо иметь невалидную дату изначально.
Например для input field. Можно же ничего туда не вводить. Наилучшее представление для отсутствующей даты — Invalid Date. То есть дата, но и в тоже время не дата.
UFO just landed and posted this here
UFO just landed and posted this here
Логично с точки зрения Number. Я прекрасно понимаю что вы имеете ввиду. Но вот с точки зрения даты — какая дата у никакого времени? Внутри конструктора Date можно было бы обойти такое «нативное» приведение типов. Из за этого приходится делать дополнительную проверку что то, что прилетело, это не null. Все остальное вернет правильный результат: либо Date либо Invalid Date.
UFO just landed and posted this here
Интересное применение, не знал об этом :) Есть только один нюанс: в рамках ECMAScript 6 многие функции работы с числами, которые в предыдущих версиях были глобальными функциями, постепенно переезжают в статические методы Number. Чтобы в светлом будущем упорядочить хаос в JavaScript и пометить как устаревшие глобальные isNaN, parseInt, ...you name it.

Number.isNaN при этом не повторяет точь-в-точь поведение window.isNaN (в новой версии отсутствует неявное приведение типов), так что трюк из статьи не прокатит :( Но спасибо, всё равно интересно было почитать.
Там все немножко по другому. Да, есть свой isNaN в Number, но это тема для отдельной статьи.
При этом, проверка на валидность даты становится проще некуда

Ну не знаю, для меня было потрясением когда конструкция типа
if (!date instanceof Date) throw new Error('Invalid Date')

не работала
UFO just landed and posted this here
UFO just landed and posted this here

Хотя, не понятно почему. NaN по IEEE 754 — одно из предусмотренных значений числа с плавающей точкой.

UFO just landed and posted this here
А с чего ей работать? В данном случае нужно try...catch использовать.

А зачем здесь try...catch? Ниже уже написали, что надо а) про приоритет операторов помнить, б) проверять на валидность, а не на соответствие типу (которая тут совсем ни при чём).

Блин, точно, тут не зачем.
Просто привык в проектах возвращать .toISOString() — оно для Invalid Date вывалит эксепшн, а тут и try...catch как раз в помощь.

Не то что бы NaN был такой полезный, скорее в JS дату на валидность не проверить по-другому. Ну неявно еще можно вот так x.getTime() === x.getTime().

Sign up to leave a comment.

Articles