Комментарии 25
В теории это ценный навык для nodejs backend разработчиков. Там ещё и не такое бывает нужно (к примеру async hooks или node fibers).
В целом про microTasks лучше знать, когда речь заходит о каких-нибудь асинхронных числодробилках. Как и о штуках вроде requestIdleCallback, requestAnimatonFrame
По моему опыту - никто даже на бэкенде в такие низкоуровневые дебри не лезет. Большинство использует сторонние пакеты, которые это все инкапсулируют. Спорить не буду что есть какие-то конторы где нужен низкоуровневый код, только вот думаю их сильно меньше, чем любителей задавать такие вопросы на собеседованиях.
в такие низкоуровневые дебри не лезет
Это не низкоуровневые дебри. Это то как раз на поверхности. По сути всё крутится вокруг того как работает event-loop. Статью не читал, 10 из 10 ответил правильно. Просто зная логику, которая стоит за этим. Promise.then выполнится в приоритетной очереди (в отличии от setTimeout), new Promise body исполняется синхронно, а .then на следующем тике micro-queue. Дальше просто внимательность.
Большинство использует сторонние пакеты, которые это все инкапсулируют
Вы о чём? Зачем вам обёртки над process.nextTick()? Что вы там инкапсулировать собрались?
только вот думаю их сильно меньше, чем любителей задавать такие вопросы на собеседованиях
Это всегда так. Но если вам нужна 3х зарплата, лучше быть готовым (и в правильные места собеседоваться).
Ей богу, одно дело жаловаться на тупые вопросы вида [] + {} + NaN === ?, а совсем другое на базу в области event loop, который вроде как святая святых.
Да и допустим спросят такое, скажем, на позицию "middle формошлёпер". Ну не ответит человек, предложат на 10% ниже зарплату. Ой беда. Такого рода вопросы нужны чтобы прощупать глубину ваших знаний. Чтобы было понимание какого рода задачи вы можете закрыть без участия более опытных товарищей.
Чем больше головняка человек может снять тем больше ему готовы платить. Умеет в soft skills и управление командой? Отлично. Знает как отлаживать удалённые nodejs процессы наживую? Прекрасно. Может на ранних этапах на code review зарезать неоптимальный BigO и предложить альтернативу? Чудесно! Специалист в области обнаружения утечек памяти? Может устроить мастер класс в области безопасности? Большой специалист в кросс-браузерной вёрстке? Ну и т.д..
Понимаю, что у вас другой опыт. Но я нигде не видел, чтобы кто-то использовал process.nextTick() напрямую. Тоже самое про requestAnimationFrame. Вполне возможно, что как раз тот самый формошлёп, о котором вы говорите.
Другой опыт. В текущем проекте:
- фронт, поиск по "requestAnimationFrame": 36 results
- бек, поиск по "process.nextTick": 26 results
Если не секрет, что за проект и для чего используете эти API?
Т.к. я 99% времени работаю с фронтом, то могу про requestAnimationFrame рассказать. В первую очередь это нужно для плавных анимаций. Будь то <canvas/>, <svg/> или что-то сделанное вручную. В целом идея в том, что это что-то визуальное и в идеале должно работать без видимых лагов, но при этом не перегружать CPU бесполезными вычислениями.
requestIdleCallback нужен когда нужно сделать что-то не супер важное, в lazy режиме, но так чтобы не в ущерб чему-то важному. Например подгрузить какую-нибудь второстепенную библиотеку.
Всякие microTask-и это, как мне кажется, всегда что-то сильно хитрое. Например нужно сделать что-то асинхронно, но как можно раньше. Скажем если у вас нагруженное nodejs приложение, то какой-нибудь setTimeout(..., 0) может запустить свой callback далеко не сразу, т.к. по пути будет 100500 promise-ов с их .then. Но можно вручную libuv заставить что-то запустить сразу первоочерёдно, но асинхронно. Полагаю в условных играх, где latency очень важен, это очень полезный инструмент. Ну или если у вас есть нужда в асинхрощине, но при этом вы используете локи редиса и не желаете его держать больше чем минимально необходимо. В общем всякое бывает.
Думаю, BuccapuoH, как и я, хотел узнать, что у вас за проект такой, в котором понадобилось столько раз использовать requestAnimationFrame и process.nextTick) И была ли в этом необходимость или же это просто преждевременная оптимизация.
Крупные SPA на 1M+ LOC. С очень разнообразной функциональностью. В том числе и графика (svg, карты на canvas, отрисовка растра), анимация.
И была ли в этом необходимость или же это просто преждевременная оптимизация.
Ну это надо каждый отдельно взятый случай исследовать под микроскопом. Но я с трудом представляю как requestAnimationFrame может быть преждевременной оптимизацией (как и оптимизацией вообще). Это как вилка и ложка. Нужно либо то, либо это. Каждой задаче свой инструмент. Вилкой есть суп просто глупо, хотя при некоторой доле сноровки возможно.
Задачки в принципе зло, но на промайзы, пожалуй, — самые бесполезные
Вот только задачки на интервью такого рода зачем? Разве они его проверяют?
Не понимаю почему нет.
Задачки в принципе зло
Не согласен.
Не проверяют, я например увидя редкого собеседующего что спросил меня о requestIdleCallback, встречно сразу спросил о process.nextTick, и попросил пример его использования, и был опечален что человек работающий фронтом не знает как устроен батчинг :с
Большая часть кто пытают этими вопросами, сами не понимают зачем их задают, не оправдывайте их
Большая часть кто пытают этими вопросами, сами не понимают зачем их задают, не оправдывайте их
Я в целом не удивляюсь тому что многие спрашивают на собеседованиях что-то, что сами нашли в сети, не вникая зачем оно им нужно и что им потом делать с ответами.
Оправдываю я совсем другое — это совершенно нормально прощупывать глубину знаний и навыков кандидата. Job-интервью это не экзамен. Это попытка понять как много головняка сможет снять с твоей головы этот человек, если его нанять. Отсутствие ответа (банальное — "я этого не знаю") это совершенно нормально. Это не "мы вам перезвоним". К примеру в банке могут спросить про тип данных decimal. Не знает кандидат? Ок, объяснят. Знает? Отлично, вероятно с финансами работал, с ним будет проще, вероятно знает специфику. Ну и т.д.
Хороший материал для улучшения понимания промисов и асинхронного выполнения
А мне он не показался хорошим. По-моему, он всё запутывает попытками обойти понятие очереди заданий и представить код обладающий какими-то статическими характеристиками. Какой ещё синхронный, какой асинхронный код? Код везде один и тот же, и выполняется он императивно в одном потоке безо всякой "одновременности". Просто некоторые вызовы (setTimeout, promise.then) добавляют переданные им замыкания в очередь заданий, которая выполняется в порядке задержки (таймаута) и приоритета. Раскраски и диаграммы, предложенные автором оригинальной заметки, по-моему, в десять раз сложнее, чем нужно.
Ну понимать как работает fetch внутри set setInterval / setTimeout пожалуй все таки стоит. А это сразу и таски / микротаски и даже возможное состояние гонки.
Материал говорит о чем угодно, но только не о promise в рамках официальной спецификации JavaScript.
Строго говоря, все описанное выше, является ничем иным как частью спецификации html5, то есть к js несли и имеет отношение, то как частный случай. Иными словами, все заявленное выше, есть суть специфическая реализация для определенной хост системы алгоритма евент луп из стандарта html5.
Как следствие, материал создает совершенно неверное представление о том, чем являются промисы в рамках именно спецификации JavaScript.
Естественно никакого евент луп, микро, макро тасков в js нет и быть не может.
Желающим проверить свои знания архитектуры js, предлагаю ответить на вопрос - каким образом в спецификации могут быть promise, если в спецификации отсутсвует хоть чтото напоминающее евент луп? Правильный ответ на сайте ecma.
Не очень понятно, что вы этим хотели сказать. Кого интересует голый JavaScript в вакууме, кроме авторов его спецификации?
JavaScript используется не только в браузере. Громадное количество разных железок, бытовой техники и даже космические корабли, содержат внутри себя Js RunTime который работает строго в соответствии со спецификацией и где никакого html5 с event loop нет, а промисы есть.
Лично у меня терминал работает под управлением V8. И это намного удобнее чем тот же Bash.
Вторая важная деталь заключается в том, что именно благодаря подобным материалам, у людей в голове каша из самого JavaScript и разного рода специфических реализаций тех или иных API. Следствием чего, существующее JS комьюнити представляет из себя, в большинстве своем специалистов не понимающих фундаментальной базы языка в результате тиражирующих мифы о нем.
Хотите практический пример? Попробуйте ответить на вопрос - возможно ли при помощи try catch перехватить exception в промисах. Если да, опишите в общих чертах как это происходит.
С высокой долей вероятности Вы дадите неверный ответ, не говоря уже о том, чтобы дать описание процесса и вины Вашей в этом нет. Вина лежит на подобных этому материалах.
Громадное количество разных железок, бытовой техники и даже космические корабли, содержат внутри себя Js RunTime который работает строго в соответствии со спецификацией и где никакого html5 с event loop нет, а промисы есть.
Ужас какой. И зачем его туда тащат. В любом случае, я думаю все эти люди на статистической грани погрешности.
Попробуйте ответить на вопрос — возможно ли при помощи try catch перехватить exception в промисах.
Я и вопроса то не понял. Какой именно case вы имеете ввиду?
try { new Promise(() => { throw 1; }); }
catch(err){ console.log('caught'); }Речь о таком коде? Я не угадал :) Не поймало. Несмотря на синхронность. Что в общем, наверное и лучше, в условиях async-await парадигмы.
Задачи? С собеса? В таком виде? Это больше на задачки с ЕГ похоже с готовыми ответами. Материал, конечно, может кому полезный, вот заголовок бы точно надо изменить.
Микрозадачи могут врезаться в последовательность выполнения в Event Loop.
потому что это микрозадача, и она была врезана в последовательность задач.
Вот это поведение интересно. На него можно прям 100% полагаться всегда и везде? или всё же будет зависить от "окружения, версии браузера, ноды и т.д."..
По ощущениям лучше избегать писать код, который на это поведение будет завязан как-то.
Никуда они не "врезаются". Просто у текущего выполняемого таска формируется очередь микрозадач (отдельная очередь, не event loop), и пока она не пустая, таск не завершается и новый не будет браться из event loop.
В старых браузерах и версиях ноды, где нет понятия "микротаск", разумеется это не будет работать.
10 задач с JavaScript Promise для подготовки к собеседованиям