Javascript и новые операторы (?? ?. &&=). Краткость vs читаемость.

[mr.jivchik]

Мне кажется «?.» — это лучшее, что случилось в js за последнее время. С этим &&= пока перебор, но и к => не сразу все пришли, а сейчас без этого никак. Ну и возвращаясь к вопросу «как вам это?». Считаю отличным, что язык развивается.

[r_gg]

фронтенд разработчик в 2037:
как написать сайт в одну строку на javaScript

[juutdzy]

Строка 21 отличная. Я бы кстати писал с if (...) else ... чтобы совсем понятно было )) Ещё один плюс с новыми операторами, вам не нужно больше обфусцировать код, он и так станет нечитаемым )))

[artemz]

Немчинский говорил что между читаемостью и краткостью нужно выбирать первое. Так как большинство времени мы читаем код (саппортим в код, написанный другим программистом), а не пишем. И каждый раз спотыкаться на хитром выражении - это повышение когнитивной нагрузки. И второй плюс данного подхода - можно дать ознакомиться с кодом бизнес-аналитику (при использовании методологии DDD). Даже у него с ''if"-ами проблем не должно возникнуть, в отличие от комбинаций знаков вопрсов, точек и прочих палочек.

[maximpodhorny]

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

[evgeniypp]

"??" и "?." must have.

Читаемость всегда важнее краткости, и эти операторы только улучшают читаемость.

"const foo = bar || baz" было очень чистым и читабельным лайфхаком, но баговало с нулём, что "??" просто исправил и стандартизировал.

Что касается "?.", то, например, очень популярный случай: "if (response && response.sales)" – читается намного хуже, чем "if (response?.sales)", особенно внутри HTML-шаблонов.

А довести до абсурда можно всё, что угодно. Не значит, что это антипаттерн.

[VIMPdev]

Еще добавят пару подобных фишек и с помощью JS можно будет вызывать дождь). А если серьезно, то как по мне знак вопроса интуитивно понятен. Особенно для тех, кто хоть немного разбирается в регулярках.

[fuad]

Дима ты просто красавчик, кроме того что ты классно подаешь материал ты ещё и подымаешь крутые темы

[andykud]

Давно не заходил на канал. Лаврик повзрослел:)))

[remkarablin]

Спасибо, что рассказал понятно, а то у меня глазки круглые были видя, что это такое :)

[yurakostin]

Признаюсь, если нет ограничений на использование библиотек (ramda, remeda), написал бы вот так:
const discountByCode = (code, sales) => pathOr(0, ['sales', code, 'value'], sales);
discountByCode(code, response);

Все эти новые операторы нахожу жутким синтаксическим мусором (думаю, что это пройдёт со временем, но всё же)

А вот оператора pipe (|>) очень жду. Напоминает elm.

Спасибо за видео, кажется, что оператор &&= я успел прошляпить =)

[sagvel]

21 строка крутяк, новые операторы тоже! Спасибо, Дима!

[zqwihmt]

Новые операторы часто использую в php, js. Первое время нужно привыкнуть, проблема в том, что когда ты сейчас пишешь, тебе все понятно, а через время читаю снова, начинаешь напрягаться больше чем с операторами с которыми работаешь чаще. Да, это дело практики и повторений, через некоторое время начинаешь все больше привыкать и сейчас почти нет разницы как писать, а для сокращения места будет плюсом. По моему самое важное для читаемости кода должно быть правильно расставлены промежуточные пустые строки, разделитель, для быстрого поглощения и анализа строк.

[fuad]

Я с первого раза все понял, это крутое новшество!!!

[sakuranasty]

первые 2 оператора очень часто использую, выручают, а вот следующие для меня новшество) Вообще я не против таких нововведений, но для маленьких функций. Если какая-то функция уже содержит кучу логики, особенно сложной, я бы использовала то, что хорошо знакомо каждому, чтобы ресурсы мозга не уходили на парс этих символов) А если в функции пара действий типа проверить респонс и отфильтровать его, то можно сэкономить строчки

[Krabaton]

Хорошо отношусь. Просто надо учить чуть больше чем один язык js, чтобы глазами не хлопать. Последнее так вообще огонь

[vitiok]

Сахар в коде ведёт себя аналогично сахару в жизни: если его немного, то он делает блюдо намного вкуснее, а если перебор, то есть это невозможно.
При работе в команде я рекомендую использовать сахар весьма ограниченно. Потому что этот код кто-то будет проверять перед мерджем в master. Идеальный случай - это когда проверяющий читает код точно так же, как читает обычную книгу: глаз легко бежит по знакомым словам и не задерживается. А вот когда человеку приходится хотя бы на несколько минут задерживаться, чтобы вкурить логику кода какого-то однострочника, это просто безвозвратная потеря времени, потому что и написать сложный сахар дольше, чем обычные if, и читать его ещё дольше. Итого, время теряется дважды, и совершенно непонятно, что выигрывается.
И ещё: optional chaining и null coalescing настолько хороши, что их начинают использовать все, всем хочется их использовать, и это действительно приводит к автоматической стандартизации кода. Но когда мы идём дальше и вводим новые излишние сущности, которые уже не так очевидно экономят время, мы эту стандартизацию убиваем, снова получая мешанину из разных подходов в одном и том же проекте...

[eldarda]

Постоянно юзаю опциональные цепочки. Еще кстати можно было сказать, что с их помошью можно вызывать функции. Если это функция, то она вызовется, иначе это не приведет к ошибке. Два вопроса как и в php так и в js очень годная конструкция, мне очень нравится

[KichatovAY]

Мне кажется, это вопрос привычки. Тернарные операторы тоже поначалу многим не заходят, потом привыкают. Насчёт последнего синтаксиса - вроде не страшно выглядит, правда ценность пока не очень понял. Лично у меня пока не было каких-то нервирующих проблем со скобками.

[FredUA]

строка 21 вообще супер. Мне очень нравится!