Типичные ошибки Node JS разработчиков

[@404piano]

Братан, хорош, давай-давай, вперёд! Контент вообще в кайф, красавчик! Можно вот этого и того, и почаще?

[@PurpleSchool]

Конечно)

[@AntonGorbachevDev]

Фанаты экстрим кода и сюда добрались со своей пастой?)

[@theban2517]

Ты каналом ошибся)

[@victormog]

За объяснения по _package-lock.json_ и _npm ci_ - отдельное спасибо!

[@PurpleSchool]

Спасибо!

[@dmitrykanaev8315]

Большое спасибо, очень годное видео! Антон, вы делаете очень большую и качественную работу, с нетерпением жду ваших новых видео и курсов!

[@PurpleSchool]

Спасибо!

[@al77ex1]

Спасибо большое за видео! Правильные подскадзки, как раз то что нужно.

[@PurpleSchool]

Спасибо!

[@СамирАбасов]

1. Спасибо за то что - когда говоришь надо писать на typescript объясняешь почему. Я уже давно слышу что надо переходить на typescript, но никто не объясняет зачем усложнять код, если обычны js работает. 2. Спасибо за адекватные цены на курсы!

[@PurpleSchool]

Спасибо!

[@-EgoSerg-]

Оооо супер. Можешь просвятить )) Возьмем пример. Есть форма, где пользователь вводит Страну и Город И у тебя есть функция, которая отсылает запрос на стороннее API И что ты сделаешь? Сделаешь два атрибута с типом строка? А валидацию не будешь делать данных от пользователе? Что если пользователь введет пустую строку, или на английском или на любом другом языке. А что если, такой страны или города не существует. А если город из другой страны? И как тут поможет ваш TS? Или вы создадите тип, где укажите все страны и все города? (и это на разных языках)

[@СамирАбасов]

@@-EgoSerg- вообще если я не ошибаюсь то ts не для этого. 1.Для лучшего понимания кода 2.Чтобы не совершать ошибки, Благодаря тому что ты укажешь что это строки, ts не позволит использовать методы не предназначенные для строк, например 3.Дополнительные бонусы (в твоей ситуации backend с помощью class-transformer проверит чтобы строка была не пустая и строка была строкой). А соответствие значения надо проверять самому

[@-EgoSerg-]

@@СамирАбасов Что и требовалось доказать. Это защита от дурака

[@shahid1508]

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

[@ВадимЛипатов-ю4ь]

Всегда приятно Вас послушать, спасибо!

[@PurpleSchool]

Спасибо!

[@petrvictorovich]

Хорошие видео! Очень мало контента с решением проблем РЕАЛЬНОЙ разработки.

[@PurpleSchool]

Спасибо!

[@alien19981]

У npm как я помню есть исключение именно для 0.X.Y версий, break changes в этом случае поднимают X, а минор и патчи Y. И вроде как ^ будет именно захватывать 0.21.1-0.21.N версии того же axios, а при релизе в 1.0.0 будет уже дефолтное поведение.

[@PurpleSchool]

Возможно для 0 действительно

[@AdamJohnson74]

Не возможно, а так и есть

[@БорисКрасных-ц8н]

По-моему, отлично. И манера подачи устраивает.

[@PurpleSchool]

Спасибо!

[@sengokusky1515]

Нужно больше Антона!

[@PurpleSchool]

Стараюсь)

[@19n1ght]

Насчет примера с callback. Для этого же есть utils.promisify. Вручную не нужно оборачивать :)

[@PurpleSchool]

Хорошее замечание!

[@chikenmacnugget]

Типичный инфоцыга. За 5 минут высрал видео про букварь не подумав и сидит с умным лицом говном обтекает

[@predok_mif]

@@PurpleSchool плюс сама реализация не правильная, что нет reject и try/catch внутри. Да, с высоты опыта оно кажется очевидным, но видео предназначено для новичков, а они слепо копируют как видят. У ютюба есть возможность вставлять всплывашка в видео без перезалива. Может добавишь такое с пояснениями и ссылкой на доку и пример?

[@yennms5547]

Спасибо, интересное видео!

[@PurpleSchool]

Спасибо!

[@alexanonymous5823]

спасибо большое, очень интересно. если есть возможность сделайте пожалуйста вторую часть где будет информация как избежать утечек памяти. В ноде огромная проблема с этим, наверное на 95% проэктов

[@PurpleSchool]

Хорошо, подумаю над этим)

[@notsure8175]

А можно про Event Loop, но прям для взрослых?) Там микротаски, макротаски, тредпулы, итд, итп. А то везде только по верхам)

[@PurpleSchool]

У меня в курсе по Node.js прям детально расписано: purpleschool.ru/course/nodejs Но может сделаю видео и сюда.

[@ruslanglaznyov9117]

kzbin.info/www/bejne/bZeaaWqJqMyepKM Неплохой доклад как по мне

[@ruslanglaznyov9117]

Все классно, но по поводу ts очень спорно. Ts код может стать очень грязным, если делаешь что-то сложное, потому что когда у тебя что-то становиться настолько обобщённым ты начинаешь программировать типы с дженериками, а не саму программу. Посмотреть те же типы в библиотеке knex и таких примеров много, а теперь представьте если бы эти типы были вместе с кодом, код был бы тяжело читаемым, это имхо конечно. К тому же не все конструкции на js можно выразить в ts, а это ограничивает. Так же у ts нет спецификации. Типы ts существуют только в рантайме. Конечно же типы нужны, так как на большом проекте сложно узнать что принимает и возвращает функция. Поэтому мне нравится подход когда мы пишем модуль, а рядом кладём файл d.ts в котором описываем типы. Затем можно в тестах из d.ts генерировать json schema и проверять типы(контракты непосредственно в рентайме). Преимущество данного подхода - Мы описываем контракты, а внутри функции/класса можем реализовывать все конструкции js, без ограничений ts. - не нужно ждать компиляции - с помощью тестов с json schema мы проверяем реальные типы. Даже на сайте ts сказано что их целью не является создать надёжные типы которые будут оказывать на возможные ошибки в компиляции, Аля rust. Их цель увеличить девелопер экспириенс, так смысл тогда использовать его, если можно делать тоже с d.ts и получать тот же экспириенс в виде подсказок в ide. Так делает команды node.js Вот ещё интересный доклад о том что ts может быть даже экономически не выгоден kzbin.info/www/bejne/fmqQd2urnbCAiM0

[@PurpleSchool]

Спасибо. Илья всегда ссылается на разработку под заказ, где экономится время. Дальше неважно как будут жить проекты. А для своих - поддержка будет крайне сложной. Что касается d.ts - они решают проблемы доков и подсказок. Но при рефакторинге большого проекта это не поможет. Да, TS для сложных случаев вносит дополнительный overhead, но проще иногда для этих случаев сделать any и договорится что опускаем сложность. Но при этом мы сможем пользоваться всеми преимуществами и не делать костыли.

[@theoty-js]

Супер доклад

[@PurpleSchool]

Спасибо!

[@vladpestsov3719]

Было бы круто про использование socketio с nodejs. Может есть такое в планах?

[@PurpleSchool]

Рассмотрю как вариант

[@petrpechkurov3095]

Антон, спасибо за видео! Про package-lock уже было в видео с интервью, благодарю за отдельное рассмотрение этого момента. Как раз сейчас на проекте этот файл в гитигноре :) Вопрос не по теме: почему используешь vim, а не neovim?

[@PurpleSchool]

Рад, что было полезно!

[@PurpleSchool]

На самом деле и то и то. Там конфиг одинаков

[@sleepyg11]

Очень интересное решение в async функции делать return new Promise(), когда функция сама заворачивается в промис автоматически. И также странный выбор использовать switch case для отображения нужного символа погоды вместо обычного объекта.

[@PurpleSchool]

1. Тебе нужно в правильный момент вызвать resolve / reject, не очень ясно как ты это собрался делать? 2. Это учебный проект, который делается для начинающих разработчиков. Можно делать и объект, можно и Map. Вопрос простого изучения студентами.

[@sleepyg11]

@@PurpleSchool async функция воспринимает return в своём блоке видимости как resolve, а throw соответственно как reject, тем самым не обязательно создавать промис внутри неё. Явное создание промиса может быть полезно когда идёт работа с каллбеками, которые нужно заворачивать, хотя в большинстве своя utils.promisify решает такую задачу для большей части стандартных случаев.

[@PurpleSchool]

Верно, мы как раз в примере оборачиваем функцию с callback. Именно поэтому используется конструкция new Promise

[@alexanders.3011]

По поводу тайпскрипта слышал что есть такая практика, когда рядом с js файлом кладут ts файл где описуют типы, мол так эффективней 🤷🏻‍♂️ Есть в этом резон или просто писать на тайпскрипте и не заморачиваться?)

[@notsure8175]

у Тимура слышал?)

[@PurpleSchool]

Проще писать на ts. Зачем делать костыли, класть d.ts и не получать в всех преимуществ, если можно просто писать на TS. Он не сложен и даёт множество бонусов.

[@2cssTV]

А в чем эффективность, если он по итогу в js транспилируется?

[@alexanders.3011]

@@notsure8175 Ага)

[@alexanders.3011]

@@PurpleSchool Ясно, спасибо за ответ)

[@bubblesort6368]

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

[@PurpleSchool]

Это верно. Иногда код типов TS слишком усложняется. Тогда надо дробить типы или иногда даже опускать их.

[@arsen_arakelian_1]

мне кажется стоило назвать видео типичные ошибки начинающих Node.js разработчиков, потому что ошибки приведены вполне банальные и обычно jun dev через пол года коммерции, все их умеет избегать.

[@PurpleSchool]

Часть ошибок встречается не только у джунов. Но в целом да.

[@suslikest3708]

Интересно было бы посмотреть тему с миграциями, например на Sequelize как там все эти связи многие ко многим и тп работают больно уж после фронта тяжко идет тема, хотя идея понятна)

[@PurpleSchool]

Ок) видео по Prisma думаю сделаю

[@antnzr656]

@@PurpleSchool typeorm 0.3 версию в nest подтянули. Почему Prisma?

[@petrplotnikov4307]

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

[@PurpleSchool]

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

[@alexanderbolshakov5915]

Вместо ручной промисификации библиотечных функций лучше использовать из библиотеки node utils promisify.

[@PurpleSchool]

Да, хороший способ.

[@ДмитрийКарпич]

Ну, Sync функции не так ужасны, зависит от того где используется. Например на старте сервера мы читаем конфиг - так один чёрт делать ничего нельзя пока его не прочитали - делаем Sync и не усложняем сущности сверх необходимого.

[@PurpleSchool]

Верно, при таком использовании они подходят.

[@surenmatinyan5386]

Можно вместо new Promise использвать promisify!!

[@PurpleSchool]

Верно)

[@alexmitelman6145]

const util = require('util'); const func = () => { /* do something */ }; const callbackPromisified = util.promisify(func);

[@ПавелШлыков-м4ч]

Ну такое себе заявление про Typescript, я думаю в первую очередь порог входа будет регулироваться архитектурой, структурой и количеством мусора на проекте. В проектах с TS может черт ногу свернуть когда люди не понимают зачем он им толком нужен и как правильно им пользоваться. Можно наплодить в 3 раза больше типов чем требуется и запутаться на ровном месте. Ну уж очень внушительным должен быть проект чтобы была польза от Typescript (при условии что он верно используется).

[@dmitriy8735]

Норм советы

[@PurpleSchool]

Спасибо!

[@ilyasdautov6218]

очень удивлен, что кто-то package-lock игнорит, когда после npm i в консоли выводится, что он должен быть закоммичен =)

[@PurpleSchool]

Верно) но очень часто вижу такую ошибку.

[@nurlankazdayev4487]

Почему fs а не node:fs ?

[@PurpleSchool]

Это одно и тоже, просто второе - это обращение в обход кэша require

[@nurlankazdayev4487]

@@PurpleSchool Спс!

[@keksinjo]

Про колбэки и промисы в ноде это не вариант, в большинстве случаев лучше стрим делать

[@PurpleSchool]

Стримы действительно лучше, но для простых случаев удобнее promise.

[@keksinjo]

@@PurpleSchool с промисами тогда можно использовать promisify из модуля util, если колбек в лучших практиках error-first, то будет посимпатичнее

[@SFUStudent]

Ошибка многих джавастриптизеров: возвращать промис не поставив перед ним await

[@PurpleSchool]

return await нужно писать только в одном случае - если ты хочешь поймать исключение в той же функции. В остальных случаях это фактически дополнительный await. Подробнее в статье: purpleschool.ru/blog/return-await

[@vovasvidinsky1369]

Na Udemy kurs stoit 100$ 🤑, mojno skidku?

[@PurpleSchool]

Лови скидочные купоны на мои курсы: t.me/purple_code_channel/155

[@just__did__it]

Что за редактор и тема?

[@PurpleSchool]

NVIM - тема github.com/yassinebridi/vim-purpura

[@НикитаИшков-в3к]

Callback hell в 2022!? ЧОООО?

[@PurpleSchool]

Да, да и не такое можно увидеть.

[@СергейКурганов-о2э]

JS без TS это как спичкой в кале ковыряться выбирая, что сдать на анализ.

[@PurpleSchool]

😂

[@chikenmacnugget]

Видос говно. Ошибки из разряда "одевай одинаковые носки в детский сад". А по поводу тс, очень спорное заявление, хотя если ты с умным лицом такие вещи затираешь, то для тебя наверное это спасательный круг.

[@PurpleSchool]

Если говно - можно было пропустить и даже не тратить время на комментарий. А про TS - тут можно не спорить, любой большой проект без него обречён на невозможность рефакторинга, поддержки длительный период и развития. На JS можно только на коленке писать проекты.

[@chikenmacnugget]

@@PurpleSchool с чего ты вывод то такой сделал? Если ты делаешь говно, то тебе говорить об этом не надо? А ну да, лучше в своем "маня" мирке капашиться. Тебе даже указали почему твой контент говно, а если ты это принять не можешь, то ты слабый. Или может тебе еще план подробный составить о том, что поправить? Ты развиваться не хочешь, ты женщина, то есть слабый. Твои заявления про ТС - это популистский спич. Любому адекватному разработчику понятно, что в первую очередь нужно в архитектуре понимать и паттернами/практиками владеть, а не отдавать все на откуп какой-то тулзы, которая сама океан проблем имеет. Если так голословно заявляешь, то сворачивай ноду, разворачивай джаву, шарп, го, элексир и т.д. А подождите там тоже можно говно неподдерживаемое написать. Регуляр инфоцыга. Владилен на минималках.

[@ruslanglaznyov9117]

@@PurpleSchool GitHub, gitlab, Netflix, без тайпскрипта. Нужно было бы лучше упомянуть важность тестов, потому что у команды тс нет цели создать надежных типов, они сами это пишут. А значит когда твой код скомпилировался у тебя ложное мнение что все работает, но это не так особенно для ts

[@PurpleSchool]

@@ruslanglaznyov9117 это полностью поддержу, так как без тестов писать код плохо. Даже если у тебя TS - тесты обязательны. TS позволяет избавиться только от части ошибок.

[@bubblesort6368]

Лишь бы какашками оббросать... Вы же должны понимать, что это смотрят люди разное уровня и для кого-то это откровение?)

[@old-cake-warden]

Вот это типичные ошибки? "Используйте TS, пишите асинхронный код, не пишите гавно". Это видео - потеря времени, как и большинство материала в интернете. Гоняют одну и ту же информацию, да ладно бы умную. Смотрите девшахту, тогда уж. Парень молодец, видео гавно

[@xeleos]

Про TS спорно. Долгая компиляция может быть проблемой. Вместо использования TS можно писать .dts файлы. Подробнее говорил создатель nodejs в интервью у бороды.

[@luckytima2315]

Райан Даль (Ryan Dahl) - основатель Node.js. Что то я не видел его у Лекса на интервью хаха

[@PurpleSchool]

А на каком моменте может быть проблемой? Сборка для прода - ожидание дополнительных 5 секунд. При локальной работе сборщики уже сильно оптимизированы и пересобирается только изменённый кусок. И даже JS мы собираем для фронта и тратим на это время и ресурсы. А писать d.ts - время траться а полной пользы от TS нет. Если уже писать типизировано, то только TS. Я ни разу не натыкался на проблемы из-за долгой компиляции.

[@bubblesort6368]

Ну может в java сборка проектов по 20 минут и проблема, но чтот ни разу не видел чтоб так долго компилился ts) это секунды в любом проекте...

[@виртуоз_ру]

Хорош 👍

[@PurpleSchool]

Спасибо!

[@-EgoSerg-]

Боже.... Просто тупо инфо циган. 1. Пример с промисами. Продолжает использовать колбек, но только завернул это еще в промисы. )) 2. По поводу TS. В примере, ты юзаешь стороннее API. И то что ты напишешь типа для данных и не пойдешь и не перепроверишь, что принимает API. Вот за это нужно бить по рукам. А что если API изменит данные. Раньше они принимали код страны, а потом стали принимать ID ты не будешь смотреть, что там и как работает? Ты будешь надеяться на свой TS? 3. Относитель npm ci Аррргггг. Ну если человеку сложно, прочитать что и как работает. Может ему не стоит программировать. Если обьяснять просто азы )) Все ясно с тобой

[@PurpleSchool]

Обожаю таких экспертов)

[@-EgoSerg-]

​@@PurpleSchool Ну конечно )) Ты ведь эксперт )))) После твоего коммента, все стало ясно и понятно )) Ты и на своих курсах такую воду льешь? Хотя, что там говорить. Есть такая поговорка. Кто умеет работать, тот работает. Кто не умеет работать, тот преподает

[@PurpleSchool]

Я же все сказал в видео: 1. Я говорил что некоторые библиотеки не поддерживают Promise и как это решить. Твой комментарий не по теме. 2. Задача TS не проверять данные от API, а задавать структуру. Проверяет разработчик логиков в коде. 3. Как и сказал в видео, это частая ошибка, потому и обратил внимание. Посмотри на канале собеседование backend, где он не знал что это такое.