requestAnimationFrame создан и существует прежде всего для того, чтобы разработчик имел четкий сигнал в какой момент, он может вносить изменения в DOM, не боясь спровоцировать reflow всей области отображения.
Вообще все таски выполняются в call stack. А в очереди они ждут, когда им нужно начать выполняться. Просто у очереди микротасок приоритет большой, поэтому ими можно заблочить main thread.
Спасибо за контент! Было бы круто увидеть полифил на промис, возможно даже на async await) requestIdleCallback - была ли у вас практика использования, хотя поддержка оставляет желать лучшего, но интересно в каком скоупе она выполняется)
По поводу promise - записал, а вот async await полифилить не получится) Его можно только транспайлить через babel или TS. RIC никогда не использовал на самом деле, use case очень редкий. Спасибо за фидбэк!
привет, крутяк) готовлюсь к собесам и тема оказалась неоч сложная. но торопишься очень сильно, и по темам слегка прыгаешь. ролик был 10 месяцев назад, надеюсь ты апнул свой скилл рассказывать)
Не все observers создают микрозадачи: - MutationObserver - создает - IntersectionObserver, PerformanceObserver, ResizeObserver - не создают, часть из них производят макрозадачи и напоминают по механике rAF, но со своими причудами Вообще observers это очень непростая история, даже rIC будут проще в сравнении с ними. Что касается rAF...это этап, который происходит когда браузер считает, что рендер документа имеет смысл, rAF это не макрозадача и не микрозадача, это отдельная задача, которая входит в список операций перед пересчетом стилей, обновлением макета и покраской. Так вот если в течении какой-либо из итераций цикла происходит запрос на rAF, то все запросы попадают в специальную карту запросов rAF. Когда наступает момент вызывать обработчики rAF, то вызываются все функции обратного вызова, которые были накоплены в эту карту на протяжении циклов/а событий. По окончанию выполнения этих функций они выталкиваются из этой карты и все происходит сначала. Вложенные rAF записываются в карту, но не выполняются, так как перед выполнением rAF делается слепок функций обратного вызова, которые должны быть выполнены, все что попало после не выполняется. Там где я прокомментировал - добротно посмеялся. Держите правило - говорите в чем уверены наверняка. Это избавит от таких умников типо меня :)
В первую очередь, спасибо большое за подробный и развернутый комментарий! Касательно rAF - я вроде бы так это и объяснил, возможно не дал достаточно внимания тому, что вызывается перед пересчетом стилей, надо пересмотреть видео. Но про то, что это отдельная сущность и живет сама по себе, я как мне помниться сказал, но скорее более примитивно, нежели ты описал. Так что снимаю шляпу. Что же касается observer'ов, я почему-то был уверен, что они создают микротаски, по поводу MutationObserver прям на 100%, но про остальные тоже где-то читал, но тут, если честно, мало хорошей инфы, да и может сам тупанул. Так что постараюсь найти и почитать. Если есть какая-то ссылка на ресурс (английский или русский - не важно), где можно это почитать, буду очень благодарен. А так, если отойти от темы, было интересно, откуда это все узнал? Не хочешь прийти на канал и поделиться опытом? По формату можно подробнее обсудить)
@@ayub_begimkulov почему я расписал rAF так подробно: потому как вы сказали, что в очередь rAF ставятся "таски" - а это не верно. Этап rAF - это одна задача, которая выполняет все запланированные запросы rAF. И также вы сказали что установка вложенного rAF будет выполнена в следующем цикле, что является не совсем точным описанием. Да вложенный rAF будет выполнен в следующем цикле, но когда этот цикл будет может пройти условно 10 циклов с макрозадачми и микрозадачами, также могут быть циклы простоя условно 5 штук, а вот потом может начаться цикл, который будет иметь документ(ы) на отрисовку и вот в этом цикле будет вызвана карта функций обратного вызова rAF. Насчет observers, я особо за ними не следил, но я точно знал что IntersectionObserver это этап который такой же как rAF в цикле событий (стоит сразу после него), он обновляет данные об пересечениях и ставит макрозадачу для документа. Остальные observers как мне известно не входят в цикл событий явно кроме ResizeObserver, он интегрируется в шаг обновления рендеринга после пересчета стилей и обновления макета. Все что я знаю это официальные спецификации "w3_org" и "html_spec_whatwg_org" (вместо пробелов точки yt удаляет явные комментарии с ссылками) В данный момент нет желания. Может когда-нибудь, возможно. Как говорится может бахнем... но потом. P.S Голос у тебя похож на мой почти один в один, я даже дежавю поймал :)
спасибо за видео! первым увидел твое видео с собесом с Муратом и затянуло, очень интересные видосы пилишь!
Да, тот собес клевый получился)
requestAnimationFrame создан и существует прежде всего для того,
чтобы разработчик имел четкий сигнал в какой момент, он может
вносить изменения в DOM, не боясь спровоцировать reflow всей области отображения.
Подскажите пожалуйста какая его связь с eventLoop?
Круто получилось, как раз думал изучить эту тему, и начал собирать материалы для этого
Рад, что смог помочь!
Спасибо большое.
Рад помочь!
Уже 9 месяцев прошло, где видео про полифил промиса?)
Вот сейчас сижу материал готовлю, будет скоро.
@@ayub_begimkulov Ждем брат, а по национальности кто вы ? Если не секрет, видно что муслим, Ма Ша Аллах1
Начало на 2:20.
Спасибо за контент, а ты не перепутал методы shift и unshift?
Ага, перепутал.
Спасибо за фидбэк!
Полезно😀
Спасибо за фидбэк!
Правильно ли я понял что микро таски выполняются прям в стеке вызова (call stack) ?
Вообще все таски выполняются в call stack. А в очереди они ждут, когда им нужно начать выполняться.
Просто у очереди микротасок приоритет большой, поэтому ими можно заблочить main thread.
мурыча смотрите про микротаски, в разносе чела по js из яндекса
Спасибо за контент!
Было бы круто увидеть полифил на промис, возможно даже на async await)
requestIdleCallback - была ли у вас практика использования, хотя поддержка оставляет желать лучшего,
но интересно в каком скоупе она выполняется)
По поводу promise - записал, а вот async await полифилить не получится)
Его можно только транспайлить через babel или TS.
RIC никогда не использовал на самом деле, use case очень редкий.
Спасибо за фидбэк!
Ты молодец! Однозначно подписка. Хочу увидеть собес на джуна со мной на твоём канале ))))
Скажи, как с тобой можно связаться - можем подумать.
Найс рассказал
Спасибо за фидбэк!
Еще есть requestIdleCallback. Вызов во время простоя браузера(когда все очереди пусты)
Спасибо, промисы будут очень кстати, а еще бы про requestAnimationFrame! Что-то никак не могу догнать как работает( Хотя я еще много чего не понимаю😅
Ахахах, постараюсь заснять что-нибудь.
привет, крутяк) готовлюсь к собесам и тема оказалась неоч сложная. но торопишься очень сильно, и по темам слегка прыгаешь. ролик был 10 месяцев назад, надеюсь ты апнул свой скилл рассказывать)
Спасибо за фидбэк!
Не все observers создают микрозадачи:
- MutationObserver - создает
- IntersectionObserver, PerformanceObserver, ResizeObserver - не создают, часть из них производят макрозадачи и напоминают по механике rAF, но со своими причудами
Вообще observers это очень непростая история, даже rIC будут проще в сравнении с ними.
Что касается rAF...это этап, который происходит когда браузер считает, что рендер документа имеет смысл, rAF это не макрозадача и не микрозадача, это отдельная задача, которая входит в список операций перед пересчетом стилей, обновлением макета и покраской. Так вот если в течении какой-либо из итераций цикла происходит запрос на rAF, то все запросы попадают в специальную карту запросов rAF. Когда наступает момент вызывать обработчики rAF, то вызываются все функции обратного вызова, которые были накоплены в эту карту на протяжении циклов/а событий. По окончанию выполнения этих функций они выталкиваются из этой карты и все происходит сначала. Вложенные rAF записываются в карту, но не выполняются, так как перед выполнением rAF делается слепок функций обратного вызова, которые должны быть выполнены, все что попало после не выполняется.
Там где я прокомментировал - добротно посмеялся. Держите правило - говорите в чем уверены наверняка. Это избавит от таких умников типо меня :)
В первую очередь, спасибо большое за подробный и развернутый комментарий!
Касательно rAF - я вроде бы так это и объяснил, возможно не дал достаточно внимания тому, что вызывается перед пересчетом стилей, надо пересмотреть видео. Но про то, что это отдельная сущность и живет сама по себе, я как мне помниться сказал, но скорее более примитивно, нежели ты описал. Так что снимаю шляпу.
Что же касается observer'ов, я почему-то был уверен, что они создают микротаски, по поводу MutationObserver прям на 100%, но про остальные тоже где-то читал, но тут, если честно, мало хорошей инфы, да и может сам тупанул. Так что постараюсь найти и почитать. Если есть какая-то ссылка на ресурс (английский или русский - не важно), где можно это почитать, буду очень благодарен.
А так, если отойти от темы, было интересно, откуда это все узнал? Не хочешь прийти на канал и поделиться опытом? По формату можно подробнее обсудить)
@@ayub_begimkulov почему я расписал rAF так подробно: потому как вы сказали, что в очередь rAF ставятся "таски" - а это не верно. Этап rAF - это одна задача, которая выполняет все запланированные запросы rAF. И также вы сказали что установка вложенного rAF будет выполнена в следующем цикле, что является не совсем точным описанием. Да вложенный rAF будет выполнен в следующем цикле, но когда этот цикл будет может пройти условно 10 циклов с макрозадачми и микрозадачами, также могут быть циклы простоя условно 5 штук, а вот потом может начаться цикл, который будет иметь документ(ы) на отрисовку и вот в этом цикле будет вызвана карта функций обратного вызова rAF.
Насчет observers, я особо за ними не следил, но я точно знал что IntersectionObserver это этап который такой же как rAF в цикле событий (стоит сразу после него), он обновляет данные об пересечениях и ставит макрозадачу для документа.
Остальные observers как мне известно не входят в цикл событий явно кроме ResizeObserver, он интегрируется в шаг обновления рендеринга после пересчета стилей и обновления макета.
Все что я знаю это официальные спецификации "w3_org" и "html_spec_whatwg_org" (вместо пробелов точки yt удаляет явные комментарии с ссылками)
В данный момент нет желания. Может когда-нибудь, возможно. Как говорится может бахнем... но потом.
P.S Голос у тебя похож на мой почти один в один, я даже дежавю поймал :)
Привет, классный контент, создавай чат в тг, чтобы можно было обмениваться вопросами, помогать друг другу
Привет, хорошая идея, надо подумать.
Создал в итоге канал в ТГ - присоединяйся)
t.me/ayub_begimkulov_coding