Темная магия JavaScript: Укрощаем неявное приведение типов

[vhlv]

Кстати, о новичках. В языке появился новый числовой тип - BigInt.

Который в языке уже лет пять как.

[rqdkmndh]

Вы, правы. Для тех кто недавно начал использовать JS - уже лет пять как. А для того кто "воюет" c ним уже не первый десяток лет - все что введено в ES6 и позднее - навсегда останется новым.

[Zulu0]

Очевидно, придется мне 7мое издание фленагана перечитать.

[Spaceoddity]

Вот с чего вы такой вывод делаете? Или это уже продвинутый уровень тролля - на комменты байтите?))

На современном JS невозможно писать не сверяясь постоянно с документацией - помимо всех этих фич ES2022, всякие браузерные АПИ постоянно добавляются и дополняются ;)

UPD: Вернее даже обратный пример - у меня есть постоянный заказчик, которому нужен код на ES5. Так вот это оказывается проблема сейчас - найти спеца, который сможет написать валидный код на es5 ;) Я сам постоянно туплю - "А querySelectorAll уже доступен? Или его придумают позже?"))

[Politura]

Я не думаю, что вот-это:

// Отключаем правило линтера для этой строки, сигнализируя: "Я знаю, что делаю"
// eslint-disable-next-line eqeqeq
if (value == null) { // Проверяем сразу на null и undefined
  // ...
}

более лаконично и дает меньше когнитивной нагрузки чем это:

if (value === null || value === undefined) { /* ... */ }

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

По перформансу тоже, приведение типов врядли будет быстрее, чем прямая проверка значения. Так что, единственная причина первого кода перед вторым, это козырнуть знаниями перед коллегами. Как по мне - так себе.

[rqdkmndh]

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

[Vitaly_js]

А зачем? По сути, паразитная инфа в которой нет никакого смысла. Да, если объяснить всем в команде, если настроить линтер в тс можно сэкономить пару токенов. Но такой ерундой заниматься, по моему, такое себе.

[ImagineTables]

if (value).

[ApxuTechTop]

Спасибо, посмеялся + понял как это реально работает

[ImagineTables]

Надеюсь, в ES когда-нибудь введут директиву, после которой на любой type mismatch будет вылетать исключение. (Это идея гораздо лучше, чем статическая типизация поверх динамического рантайма и лучше, чем ===. Я писал на таком языке и знаю).

[k12th]

У статической типизация поверх динамического рантайма преимущество в том, что type mismatch поймает разраб в IDE, а не юзер на продакшене.
С другой стороны, конечно, такие случаи на проде приучают писать более аккуратно и ответственно.

[dyadyaSerezha]

Вы не на ту мысль ответили. Как я понял коммент, лучше статическая типизация со статическим рантаймом.

[ImagineTables]

поймает разраб в IDE, а не юзер на продакшене

Так тесты писать надо. Или хотя бы запускать написанное и смотреть (это тоже тесты, но не автоматизированные).

[winkyBrain]

// Версия "боюсь и избегаю":
if (value === null || value === undefined) { /* ... */ }

// Версия "знаю и использую":
if (value == null) { /* ... */ }

Второй вариант короче, чище и абсолютно безопасен, так как null по нестрогому равенству дружит только с undefined. Это общепринятая идиома в мире JS.

Какие-то проверки курильщика, вы правда станете использовать это вместо

// версия "а зачем там вообще был null?"
if (!value) { /* ... */ }

Здесь тоже будет приведение типов, куда допом проскочет и 0, пустая строка. Собственно это наверное единственное место, подобные проверки, где стоит помнить о приведении типов всерьёз, потому что массивы с примитивами вряд ли кто-то складывает, находясь в своём уме. В общем нелепо как-то

[Annsky]

Если тип value - undefined | null | number, код сработает ошибочно на значении 0
Проверка value == null нужна как раз, чтобы проверить только undefined и null, как отсутствие значения, принимая 0, пустые строки как наличие значения.

[Vitaly_js]

Думаю в статью можно было добавить бесячий пример с null | undefined, когда как раз раньше нужно было использовать длинное выражение, а теперь просто один оператор:

const f = (a === 100) => { console.log({ a }) }
f()
// => { a: 100 }
f(null)
// => { a: null }

Поэтому если у нас есть null | undefined:

const f = (a: number | null | undefined) => {
  a = a ?? 100

  console.log({ a }) // a: number
}

f(null)
// => { a: 100 }

Таким образом единственное "правильное" использование "==" становится еще более ограниченным.

[tenzink]

Можно понять как работает этот ужас, найти логику и скрытую красоту, заработать Стокгольмский сниндром. Но называть "фичёй", это перебор. Проектируй кто сейчас новый язык, разве стал бы творить такое?

[Spaceoddity]

Для браузера в котором не надо считать всю бизнес-логику?

[black1277]

Вот еще интересный пример:

const n = null
const f = 0
console.log(n < f) // false
console.log(n > f) // false
console.log(n == f) // false
console.log(n >= f) // true
console.log(n <= f) // true

[rqdkmndh]

Тот самый случай, когда ваша логика оказывается бессильной супротив спецификации. По логике - либо третье выражение должно быть true, либо последние два - false. Для ясности представьте, что с обеих сторон везде стоит цифра ноль. Но в спецификации прямо прописано: true может быть только при сравнении с null или undefined! Не стал включать этот пример, так как даже у тех кто считает себя "знающим" - частенько вызывает диссонанс и раздражение.

[Wowfirst]

Для кого как, но IMHO лучше не морочить голову себе этими приведениями, а просто использовать typescript и забыть навсегда про все эти сюрпризы с типами