Спасибо большое вам за такие лекции! Cижу, как одержимый, наслаждаюсь полным погружением. Материал качественный. Отличная практика после статей на learn javascript. Кому то очень повезло иметь такого преподавателя. У нас же в вузе все вертится вокруг продуктов Microsoft и языка программирования C#.
Семен Беленко и правильно, что вертится вокруг C#. Как мне кажется, это более адекватный язык, абстрагируясь от того, что он разработан в недрах корпорации зла. Уж в качестве первого языка он подходит куда лучше чем JS. C# - это по-моему единственное, что MS сделали хорошего. Ну и Visual Studio Community, конечно. Реабилитируются после всех подстав с IE, когда они подложили свинью всем разработчикам и надо было всегда думать, а будет ли это работать в IE или нет, что-то дописывать конкретно под IE. Хреново, что JS в свое время стал практически монополистом во фронтенде и приходится его изучать. C# в разы приятнее.
@@phat80 По мне так вообще несправедливо сравнивать скриптовой язык и компилируемый. JS и C# не одного и того же поля ягоды. И JS гораздо круче в общем плане. Не потому, что я считаю его лучше С# как язык программирования. А потому что слово "круто" включает в себя многие факторы и конкурентноспособность и способность выходить на новые рынки в том числе. JS сейчас перетягивает практики архитектуры и написания кода из C# и становится лучше.
@@maksimsergeevich5939 ну это просто смешно, вот так однозначно заявлять, что JS лучше ))) вообще сам JS - это ничто без интерпретатора и от качества его написания. Так что получается круче всех до сих пор C++, за счет чего и JS сейчас быстрый и эффективный.
Спасибо за лекцию! Заметил что если после catch хотим продолжить цепочку then-catch то нужно и из catch возвращать промис. А то на следующий then не попадёт не каких аргументов (Конечно это актуально в тех случаях если в catch не бросаете ошибку (throw error))
Из catch и из then не нужно возвращать промис, нужно возвращать значение, тогда оно упаковывается в промис и идет по цепочке, если из catch или then вернуть промис, то двойной упаковки в промис не случится (промис в промис не положится), но делать это специально не нужно, возвращайте просто значение.
@@TimurShemsedinov Аа ну да, catch тоже возвращает промис. Так что не нужно в блоке catch создавать лишний промис. Спасибо за то что исправили и за идею ☺️
Про Promise.race вы ошиблись, это примерно на 35:05 про reject, Вы говорите "Если все три вернуться с ошибкой то ..." а вот нет, вся суть в том что в catch мы попадем сразу как только любой из промисов вызовет reject. точно также как и в then попадем как только любой вызовет resolve, т.е. это типа "кто первый встал того и тапки" независимо от того reject или resolve
32:12 А когда начинает промис исполняться? Не в момент создания? Разве не должны на момент начала исполнения Promise.all уже улететь все http-запросы? Upd: Проверил. Улетают. Кстати, в 8-all.js в 5 строке ошибка: если не убрать прямой слэш в конце урла, то на все запросы, кроме корневого, server.js будет выдавать ошибку 404, т.к. роуты person и city будут резолвиться в //person и //city. PR сделаю. В 9-all.js это можно использовать для демонстрации .catch().
Ускорились, но в 3-4 раза медленнее, это не принципиально, потому, что все асинхронные операции используются вместе с вводом-выводом, он занимает минимум в 10000 раз больше времени, так что скорость работы контракта в этом растворяется
Тимур спасибо и за эту лекцию! Не первый раз ее смотрю кстати уже. Периодически пересматриваю многие ваши видосы по темам в которых у меня возникают вопросы. И снова очередной вопрос у меня =) : Если функция асинхронная, она возвращает промис в любом случае если что-то возвращает. Но я видел примеры где внутри асинхронной функции return new Promise(). В этом случае не получается масло масляное? Я понимаю, возможно таким образом хотели получить методы resolve и reject, но ведь в этом случае мы можем использовать await, try, catch. Так есть ли смысл внутри асинхронной функции писать return new Promise() ? Я так и не понял пока что.
В этом случае промис в промис не оборачивается, т.е. 2 раза await писать не придется, зачем так делают - нужно смотреть код, возможно, там цепочка .then.then.then... уже внутри функции и распаковывать ее через await нет смысла, ее так и возвращают, а может просто лишний код, это часто случается.
а що краще використовувати на хай-лоад проектах, Promise.race чи async.race? Де буде кращий перформанс? З одної сторони async.race написаний на колбеках, а з іншої це 3-party бібліотека. Чи є щось подібне у metasync ?
Promise краще, зараз він вже має багато оптимізацій, але неможна ставити питання так. Спосіб написання асинхронності не повинен впливати на продуктивність сервера, майже усе навантаження бере I/O, а колбеки та проміси це майже невідчутно
2:30 Забавно, что у setTimeout параметр таймаута - необязательный. Но нигде не написано, чему он будет равен, если не указать. Ни в МДН, ни в спецификации HTML. Нет, интуитивно-то я понимаю, что должен быть 0. Но с таким же успехом и 1 может быть. :)
А почему не сказано за разницу второго аргумента then c catch? Это не абсолютно идентично, в React советуют не использовать catch в промисе в useEffect, а вторым аргументом в then обрабатывать ошибки. Какая у них разница?
Порядок обработки разный, второй аргумент .then раньше получает ошибку, чем .catch, но если ошибка произойдет в одной из функций, которые переданы в .then, то дальше ее уже в .catch можно схватить
По Promise.all() и Promise.race() не до конца понял почему в первом случае callback содержит респонз всех запросов, а во втором случае только первого. Это потому что в первом случае после каждого запроса они собираются в коллекцию и только после этого выполняется resolve()? А во втором он сразу же выполняется на первом успешном запросе?
Тимур, моё почтение, спасибо =) Продолжаем Асинхронный курс =)
Спасибо за лаконичность и доступность изложения! Подписался.
Какая лаконичность ?? Вы наверное не видели "лаконичных" видео
Спасибо большое вам за такие лекции! Cижу, как одержимый, наслаждаюсь полным погружением. Материал качественный. Отличная практика после статей на learn javascript. Кому то очень повезло иметь такого преподавателя. У нас же в вузе все вертится вокруг продуктов Microsoft и языка программирования C#.
C# же хороший язык да и net core кроссплатформа давным давно
Семен Беленко и правильно, что вертится вокруг C#. Как мне кажется, это более адекватный язык, абстрагируясь от того, что он разработан в недрах корпорации зла. Уж в качестве первого языка он подходит куда лучше чем JS. C# - это по-моему единственное, что MS сделали хорошего. Ну и Visual Studio Community, конечно. Реабилитируются после всех подстав с IE, когда они подложили свинью всем разработчикам и надо было всегда думать, а будет ли это работать в IE или нет, что-то дописывать конкретно под IE. Хреново, что JS в свое время стал практически монополистом во фронтенде и приходится его изучать. C# в разы приятнее.
@@phat80 ты такие вещи на этом канале не пиши)
А вообще с 2015 - года JS уже стал более - менее юзабельным языком. Могло быть и хуже
@@phat80 По мне так вообще несправедливо сравнивать скриптовой язык и компилируемый. JS и C# не одного и того же поля ягоды. И JS гораздо круче в общем плане. Не потому, что я считаю его лучше С# как язык программирования. А потому что слово "круто" включает в себя многие факторы и конкурентноспособность и способность выходить на новые рынки в том числе. JS сейчас перетягивает практики архитектуры и написания кода из C# и становится лучше.
@@maksimsergeevich5939 ну это просто смешно, вот так однозначно заявлять, что JS лучше ))) вообще сам JS - это ничто без интерпретатора и от качества его написания. Так что получается круче всех до сих пор C++, за счет чего и JS сейчас быстрый и эффективный.
Спасибо за лекцию!
Спасибо за лекцию! Заметил что если после catch хотим продолжить цепочку then-catch то нужно и из catch возвращать промис. А то на следующий then не попадёт не каких аргументов (Конечно это актуально в тех случаях если в catch не бросаете ошибку (throw error))
Из catch и из then не нужно возвращать промис, нужно возвращать значение, тогда оно упаковывается в промис и идет по цепочке, если из catch или then вернуть промис, то двойной упаковки в промис не случится (промис в промис не положится), но делать это специально не нужно, возвращайте просто значение.
@@TimurShemsedinov Аа ну да, catch тоже возвращает промис. Так что не нужно в блоке catch создавать лишний промис. Спасибо за то что исправили и за идею ☺️
Круто!!! Спасибо:))
Вы просто преподаватель и профессионал с больших букв П
Про Promise.race вы ошиблись, это примерно на 35:05 про reject, Вы говорите "Если все три вернуться с ошибкой то ..." а вот нет, вся суть в том что в catch мы попадем сразу как только любой из промисов вызовет reject. точно также как и в then попадем как только любой вызовет resolve, т.е. это типа "кто первый встал того и тапки" независимо от того reject или resolve
Да, согласен, сейчас исправлю видео, че-то я заговорился
32:12 А когда начинает промис исполняться? Не в момент создания? Разве не должны на момент начала исполнения Promise.all уже улететь все http-запросы?
Upd: Проверил. Улетают. Кстати, в 8-all.js в 5 строке ошибка: если не убрать прямой слэш в конце урла, то на все запросы, кроме корневого, server.js будет выдавать ошибку 404, т.к. роуты person и city будут резолвиться в //person и //city. PR сделаю. В 9-all.js это можно использовать для демонстрации .catch().
Спасибо!
Скажите Тимур, можно ссылку на лекцию о создании серверов, про которую вы говорили в видео?
Я не помню про что я говорил 4 года назад, но возможно, про ruclips.net/video/-az912XBCu8/видео.html
А стоит ли отменять те запросы, которые не доходят до promise.race()??
Чтобы не грузить сервер, например, лишним процессом?
Интересно спустя 4 года промисы в ноде по скорости очень близко подошли к колбекам ?
Ускорились, но в 3-4 раза медленнее, это не принципиально, потому, что все асинхронные операции используются вместе с вводом-выводом, он занимает минимум в 10000 раз больше времени, так что скорость работы контракта в этом растворяется
Тимур спасибо и за эту лекцию! Не первый раз ее смотрю кстати уже. Периодически пересматриваю многие ваши видосы по темам в которых у меня возникают вопросы. И снова очередной вопрос у меня =) :
Если функция асинхронная, она возвращает промис в любом случае если что-то возвращает. Но я видел примеры где внутри асинхронной функции return new Promise(). В этом случае не получается масло масляное? Я понимаю, возможно таким образом хотели получить методы resolve и reject, но ведь в этом случае мы можем использовать await, try, catch. Так есть ли смысл внутри асинхронной функции писать return new Promise() ? Я так и не понял пока что.
В этом случае промис в промис не оборачивается, т.е. 2 раза await писать не придется, зачем так делают - нужно смотреть код, возможно, там цепочка .then.then.then... уже внутри функции и распаковывать ее через await нет смысла, ее так и возвращают, а может просто лишний код, это часто случается.
а що краще використовувати на хай-лоад проектах, Promise.race чи async.race? Де буде кращий перформанс? З одної сторони async.race написаний на колбеках, а з іншої це 3-party бібліотека. Чи є щось подібне у metasync ?
Promise краще, зараз він вже має багато оптимізацій, але неможна ставити питання так. Спосіб написання асинхронності не повинен впливати на продуктивність сервера, майже усе навантаження бере I/O, а колбеки та проміси це майже невідчутно
@@TimurShemsedinov зрозумів 👍 дуже дякую
2:30 Забавно, что у setTimeout параметр таймаута - необязательный. Но нигде не написано, чему он будет равен, если не указать. Ни в МДН, ни в спецификации HTML. Нет, интуитивно-то я понимаю, что должен быть 0. Но с таким же успехом и 1 может быть. :)
А почему не сказано за разницу второго аргумента then c catch? Это не абсолютно идентично, в React советуют не использовать catch в промисе в useEffect, а вторым аргументом в then обрабатывать ошибки. Какая у них разница?
Порядок обработки разный, второй аргумент .then раньше получает ошибку, чем .catch, но если ошибка произойдет в одной из функций, которые переданы в .then, то дальше ее уже в .catch можно схватить
какая IDE?
ru.m.wikipedia.org/wiki/Midnight_Commander
Не вижу особой выгоды от обёртке - promisify
Такая же выгода, как от паттерна адаптер, это преобразование контрокта, например, когда есть зависимость на колбеках и мы не можем ее переписать
@@TimurShemsedinov А что такое контракт?
Ничего не понятно
Так и должно быть
@@TimurShemsedinov это потому что она женщина ?
По Promise.all() и Promise.race() не до конца понял почему в первом случае callback содержит респонз всех запросов, а во втором случае только первого.
Это потому что в первом случае после каждого запроса они собираются в коллекцию и только после этого выполняется resolve()? А во втором он сразу же выполняется на первом успешном запросе?
Спасибо!