Друзья, всем спасибо за просмотр! Во время пересмотра записи заметил, что звук у меня и Сергея был разной громкости и noise gate был настроен чуть агрессивно, из-за чего мою речь иногда вырезало. Постараюсь поправить все к следующему собесу. Также заметил, что я использую термин “контекст функции”, вместо “скоуп функции” (на 01:18:50, но вроде было еще пару моментов). Если еще что-то проглядел -- делитесь в комментариях.
31:38 Насколько я знаю, рендеринг происходит перед макрозадачей. Поэтому setTimeout всегда должен выполняться после изменения стилей. 35:16 Круто, не знал.
спасибо, ребят! Серёга, молодец, на запись сложно отвечать на рандомные вопросы)) все мы люди, у всех есть нервы!) Большой молодец! Аюб, респект за разбор raf, крутой фидбек оставил, очень по-доброму))) удачи вам обоим!)
Хороший показательный собес, когда разрабы в принципе говорят об одном и том же , но не могут понять друг друга) к слову о том что отсобесить человека очень сложно
Немного режет фраза "мейн тред", она в вебе неприменима, т.к. мы всегда в мейн трейде (не считая всякие тонкости работы со скроллом, с слоями, ну и с воркерами). Будто автор из Android разработки пришел в веб :) По теме вопросов, довольно пугает, что про event loop спрашивают на всех собесах, но почти всегда даже сеньеры грешат кучей рефлоу, перерасчетом стилей множества элементов вместо одного, непониманием композитных слоев и прочим. Та же самая тема с замыканием, спрашивают всех, а понимание внутренней работы хуков их реакта ни у кого нет (и природу проблем хуков при неправильной передаче в них зависимостей). Ощущение, что либо надо спрашивать что-то практичное, либо углубляться в вопросы, а не спрашивать то, что есть в методичках по собеседованию. Я бы лучше дал пример - исправь проблему тяжелой отрисовки или перерасчета стилей. Пусть хоть дома сидит над этим, загуглить все равно не сможет. Но если посмотреть в реале, то можно будет увидеть, как человек умеет пользоваться инстурментами девтулзов и как понимает работу отрисовки браузера. С другой стороны, если человек пишет в основном админки и всякий бэкофис, то эти знания ему абсолютно не нужны, и лучше спросить что-то предметное. А если он пишет большой продукт, который должен плавно работать на слабых мобильных устройствах, вот тогда нужно мучить его по теме отрисовки браузера (и никогда не найти специалиста :) ).
Ваше замечание подобно - немного режет фраза "мы ходим пешком", так как мы всегда ходим пешком ( не считая всяких кто ездин на машине, метро и автобусе) В настоящий момент стандарт дефакто - это программирование с использованием минимум олного воркера - причем именно в нем и лежит основная логика работы веб приложения. Это сервайс воркер. А то что Вы ляпнули, характерно было для 2014 года, когда воркеры только появились на горизонте.
@@demimurych1 ну а вы придрались к самому незначительному абзацу в моем комментарии. Я просто в шутку хотел сказать, откуда пришел автор видео. Но если серьезно, то вы неправы: Во всяких нативных приложениях действительно, крайне часто всякую работу выносят в отдельный поток, чтобы не нагружать основной поток, который выполняет рендер. И даже в некоторых технологиях можно через Invoke из потоков менять интерфейс, предварительно залочив его объекты. По этой причине там нужно упоминать, в каком мы треде. Для веба нет стандарта дефакто по потокам. Вебовские воркеры не полноценные потоки, они не умеют в шаред мемори в основным потоком (не считая типизированных массивов), они не умеют в lock. По сути по своим возможностям они приближены к процессам а не потокам, т.к. внутри себя создают контекст (полноценный window объект), создают свой event loop даже со стадией рендера (см. OffscreenCanvas), они не умеют общаться друг с другом через прямое обращение к памяти. т.е. вебные воркеры это дорого - передача данных требует сериализации, создание потока требует создания контекста с кучей выделенной памяти. Часто в проекте с воркерами спрашиваю "вы же, ребят, больше ресурсов тратите на подготовку сообщений в воркер, чем на вычисления в нем. Зачем он вам?", а тебе в ответ "не знаю". В 99.9999% проектов в вебе не будет воркеров или они есть, но неэффективны, поэтому у нас не говорят "мэйн тред". > А то что Вы ляпнули, характерно было для 2014 года В 2014 году было больше воркеров чем сейчас, т.к. тогда люди по ошибке думали, что они эффективны. Сейчас же многие разобрались, и крайне редко тащат их в проект, только для тех задач, где нужно минимум общения с воркером и куча работы в нем. У нас куча асинхронщины, поэтому можно строить классный интерфейс без воркеров, а тяжести выносить на бэкенд.
@@Владимир.П-е9о Вы так тролите? Причем тут нативные приложения? при чем тут invoke? Для веба есть стандарт дефакто по тому как организовывать потоки для выполнения кода JS. Открывайте официальную спецификацию ECMA и читайте до просветления. С 2014 года существует все необходимое закрепленное официальной спецификацией для организации паралельного выполнения кода и доступа к разделяемой потоками/процессами памяти. В том числе и мьютексы/локи состояние гонки и прочие прелести паралельного выполнения кода. Нет не приближены к процессам. Спецификация позволяет делать то, что угодно runTime для решения задач паралельного выполнения кода. И совершенно все равно процессы там под капотом или потоки. Результат там один единсвенный. В V8 под капотом - thread-ы. > т.к. внутри себя создают контекст (полноценный window объект), Вы несете чушь. window обьект - это global object для стандарта HTML5. И он присуствует только там. И даже там, есть еще 11 разных типов глобальных обьектов - по колличеству типов worker-ов. Которые ничего общего с window не иемеют. Прекратите сорить терминами смысла которых Вы не понимаете. >т.е. вебные воркеры это дорого - передача данных требует сериализации, создание потока требует создания контекста Вы снова несете чушь. Открывайте спецификацию и читайте что такое Atomics операции. Вы несете чушь еще больше, когда упоминаете слово контекст, не понимая смысла этого слова в рамках спецификации языка JS. При этом Вы не ограничиваетесь и несете чушь даже в академическом смысле слова того чем являются потоки. Стратегия наговорить "умных" слов работает только тогда когда вы общаетесь с неучем подобно Вам. а не с человеком который в том числе писал спецификацию. >В 2014 году было больше воркеров чем сейчас, т.к. тогда люди по ошибке думали, что они эффективны. Вы несете глупости. Стыдитись. Воркеры не могут могут быть эффективны или не эффективны хотя бы потому, что есть вещи которые вы можете сделать ТОЛЬКО при помощи воркеров - например контроль за сетевым взаимодействием вашего приложения с вашим сервером. Или например использования всех возможностей предлагаемым HOST средой браузера для создания оффлайн приложений. Ничего подобного без воркеров Вы не создадите в принципе. Потому, что только в воркерах есть подобный функционал. И это не касаясь главного - воркеры позволяют Вам распаралеливать нагрузку на доступные вычислительные ресурсы архитектуры где выполняется Ваш код. Вы Неуч. И что хуже всего неуч воинствующий, который считает что заучив пару терминов спецификации, он будет ставить "на место" тех кто боится туда заглянуть. Прекратите позориться, и дайте себе труд хотя бы раз в жизни прочитать спецификацию.
В решении sum есть баг: const f1 = sum(1)(2); const f2 = f1(3); console.log(f1() + f2()); // напечатает 12 хотя должно быть 9 мой вариант const sum = (v) => v == null ? 0 : (v1) => v1 == null ? v : sum(v + v1);
Мы в решении только один раз замыкание создавали на result, а затем к нему уже суммировали все. То есть каждый последующий вызов добавлял в один и тот же result и возвращал одну и ту же функцию calculate.
@@ИмяФамилия-э4ф7в f1 = sum(1)(2); - вот здесь будет 3 f2 = f1(3); - а здесь 3 + 3 = 6, потому что стартуем от f1, т.е. это как sum(1)(2)(3) f1() + f2() = 3 + 6 = 9
Спасибо за твои видосы, после них реально начал больше понимать как работает реакт на практике и даже если не знаю ответы на вопросы в интервью, то зачастую получается до них дойти через рассуждения. Собес получился интересным и по фидбеку все четко!
Спасибо за видео. Решение задачи function sum() { let v = 0; if (arguments.length === 0) { return 0; } else { v = arguments[0] } return function inner() { if (arguments.length === 0) { return v; } else { v = v + arguments[0]; return sum.call(null, v); } } }
Что-то ты перемудрил. function sum(num) { let result = 0; function inner(nextNum) { if(!nextNum) return result; result += nextNum; return inner; } return inner(num); }
Ребят, не знаю реальный ли это собес и реальный ли собеседуемый, но я на самообучении за полгода все эти концепции изучил в разы лучше кандидата из видео + тонну дополнительной информации. Но, в любом случае, за видео спасибо! Повторять материал тоже надо. P.S. Кстати, из обсуждения renderQueue или CRP (кто как называет) вы нечетко проговорили этап style (recalculation), который вызывается между rAF и layout. А именно, в этот момент браузер стечит DOM и CSSOM, вычисляет активные @media, что в итоге формирует render tree. И уже за этапом style (recalculation) идет этап layout.
@@TarasovFrontDev привет! Во 1) это был я, а во 2) во фронте оч много вопросов, которыми можно задушнить. По теме обновления документа -- если ты не работаешь с анимашками/видео, то не будешь практиковать эти темы, а каждые несколько месяцев держать в уме бесполезные знания, которые можно погуглить/уточнить у коллег -- такое) Есть куча гораздо более важных тем, но в целом это одна из сотни важных тем)
