Михаил, это были очень познавательные 8 минут)) Спасибо, наконец-то всё по полочкам с useCallback. На проектах все, в том числе я, его использовали неправильно.
Михаил, спасибо вам за разъяснение useCallback, его лепят везде где нужно и не нужно и никто не понимает особо, зачем он нужен)) Теперь за 8 минут вашего видео все стало на свои места!! От вас контент просто бесценный!!))☺👍 Лайк однозначно!))
До этого видео я не мог понять для чего useCallback и как ей воообще пользоваться. Видео супер полезное. Частно тут нахожу что-то для себя, спасибо! (Самоучка)
Михаил, это огонь! У меня коллеги тоже любят обернуть банальное сравнение 2х переменных в мемоизацию, не парясь, что мемоизация сильно дороже элементарного сравнения 2х примитивов) нужен баланс между «я вообще ничего не знаю про мемоизацию» и «я мемоизирую каждый чих»
Михаил, спасибо большое! Смотрел твой бытрый курс по React Router, и тут после третьего видео CZcams "подсунул" мне это видео. Думал не смотреть, ведь "-да что я ещё могу узнать про useCallback?", оказалось, что ключевую вещь😅. Спасибо! Теперь буду тщательно думать перед решением мемоизации сущностей🤝
"один мой коллега засунул целый реакт-компонент в useCallback" - ааааа!!! господи, я думал только у нас такая дичь в проекте) как же я устал бороться с этими мамкиными оптимизаторами) спасибо, теперь кроме видоса айти синяка, буду кидать еще ваш )
Привет, спасибо за видео! Наконец-то кто-то правильно объяснил, потому что все видео на эту тему содержат неправильную информацию и какие-то глупые надуманные примеры, не имеющие отношения к реальному миру.
Есть еще коллбэк-рефы, когда функция принимает как аргумент node (dom-узел) и присваивается атрибуту ref в JSX. Используется это обычно для передачи dom-узла кастомному хуку. useRef не всегда тут может помочь, ибо useEffect на него не реагирует, а вот коллбэк-реф он увидит.
Михаил, спасибо Вам за ваши труды! С удовольствием смотрю Ваши курсы на Udemy. Планируете ли Вы какой-нибудь новый курс? Очень хотелось бы, раскрыть тему CI/CD Jenkins.
Спасибо огромное, это лучшее объяснение useCallback во всех интернетах! Но я только одного не понял - зачем линтер требует добавить logUpdate в массив зависимостей во втором примере? Какая тут логика?
У нас в конторе принято всегда оборачивать. Я уже устал спорить, поэтому просто делаю че просят )) А в целом да, знаю давно, что это шляпа каждый раз мемоизировать. Еще есть другой фетишь: юзмемо. Каждую букву заворачивают 😅
C useMemo чуть сложнее. Здесь мы просто создаем функцию, не вызывая ее. А useMemo предполагает мемоизацию вычислений. Поэтому иногда данный хук нам может пригодиться, чтобы не повторять дорогих вычислений, даже если мы не планируем передавать их в другой компонент. В целом, логика с memo и использованием массивов/объектов как зависимостей для других хуков - аналогичная. Но, повторюсь, есть и другие кейсы использования.
если можно о useEffect но с акцентом на помещение используемой в нем функции в массив зависимостей. линтер этого требует. но вот сегодня поместил и получил кольцевую обработку. как в видео. в случае когда мы не можем поместить функцию внутрь эффекта. например она вообще берется из собственного хука.
Забыли сказать про ментальную нагрузку) Минимальный оверхед который дает useCallback не стоит возможных проблем с производительностью в местах где забудешь обернуть в useCallback. Так что с практической точки зрения всё лепить в useCallback имеет смысл
господа, сколько не смотрел не могу понять разницу между useMemo, useEffect, useCallback. Даже после просмотра этого видео не до конца понял всю ситуацию с useCallback. Если не сложно, можете подробно разъяснить или скинуть ссылку на какой-то источник с подробным объяснением.
useCallback возвращает функцию, а useMemo возвращает уже готовое значение, например объект. А так, суть одна и та же - возвращать ссылку на одну и ту же сущность, если зависимости не изменились.
Михаил, вы волшебник. Я только учусь и вчера убил весь день на решение проблемы лишнего рендеринга. А тут ваш видосик подоспел как раз вовремя. Осталось придумать как это все состыковать с useForm :)) Спасибо вам большое за контент.
Grand merci à vous, но обращаю внимание уважаемого автора на потенциальную оговорку 8:03: по всей видимости, вместо фразы "два кейса когда нам нужен useEffect()" имелось в виду "два кейса, когда нам нужен useCallback()"? Поправьте, если не так
Спасибо, Михаил, у Вас наконец-то появились нормальные коллеги. Судя по объяснению данного хука в рамках курса по Реакт, достойных и мотивирующих коллег у Вас на тот момент не было!))
@@mishanep Михаил, если я правильно понял предисловие, то до сегодняшнего дня у Вас были коллеги, твердо знавшие когда и в каких сочетаниях использовать useCallback))
Оно там звучит примерно как "на всякий случай". Если команда небольшая и понятно как хуки будут использоваться, то оборачивать всё подряд было бы странно. Если пишем библиотеку, то уже выглядит логично.
Я без доки для себя взял это правило. На самом деле тут двояко. Из плюсов - уменьшается ментальная сложность. Нам не нужно каждый раз заходить в хук и проверять, обернута ли функция, если мы ее используем в зависимостях в компоненте. Из минусов - уменьшается читаемость кода и увеличивается время написания. Немного увеличивается ментальная сложность при работе с хуком.
useCallback и memo - это не бесплатно, не факт, что в попытках оптимизации, всё не стало гораздо медленнее, чем без них. Нужны пруфы, пока же видно лишь то, что нет смысла использовать на столь легковесных компонентах лишнюю оптимизацию.
а как же removeEventListener, там необходимо передавать функцию с изначальной ссылкой, и соответственно для этого мы можем callback функцию, передаваемую в addEventListener обернуть в useCallback - чтобы не потерять ссылку на нашу изначальную callback функцию)
Можно забить на useCallback, если ты передаешь свой колбек в какой-то самый простой компонент. Или когда данные, от которых он зависит, постоянно обновляются, и ты точно знаешь как он устроен внутри. А вот взаимодействие с DOM, это уже дорогая операция, это дороже чем инициализировать функцию, и чем 10 функций. А еще очень часто есть много готовых компонентов и компонентов из сторонних модулей, и как на это повлияет использование useCallback, заранее не известно. А выстрелить это может в самый неподходящий момент, заблокировать юзеру страницу, сожрать всю память или вылететь с переполнением стека вызовов. По этому, из соображений безопасности и здравого смысла, использовать useCallback надо для каждой объявленной внутри компонента функции, которая зависит от данных в этом компоненте. В противном случае ей там делать нечего, и она должна быть объявлена вне компонента.
Ну вот эти слова про "дорогую операцию" ничем не подкрепленные, вообще не айс. Сам то проверял или так просто, услышал от кого-то, кто сам услышал от кого-то и т.д., и так вы просто повторяете бездумно друг за другом? Что там с holy js кстати, едешь/не едешь?
Типичное поведение практически всех современных программистов, в т.ч. высокого уровня - это слепое следование каким-либо догмам, не пытаясь разобраться, насколько они актуальны и в каких случаях. Туда же ничем не подкрепленные заявления о низкой / высокой производительности, бесконечная битва с ререндерами (в SPA), бОльшая часть которых на производительность с позиции end user влияет практически... никак. А потом имеем глючное нечто типа сайта Озона (там Vue, но в данном случае это иррелевантно) с вот уже годами (периодически) отваливающейся фильтрацией. Таковы реалии современного программирования "по фэн-шую".
Тут скорее дело не в том, дорогая операция или нет. Это в любом случае профилировать надо тогда. Оптимизация просто не нужна, если нет видимых проблем с перформансом. А оптимизация не бесплатна больше в плане то, что мы пишем лишний код/обертки, увеличиваем ментальную сложность. Пускай мы даже ускорили работу компонента, если в реальном использовании этого не видно, это нет смысл.
Автору и некоторым комментаторам не мешало бы мат часть подтянуть. Не так страшен ререндер, сколько перемонтирование в дом. Вот так насмотрятся таких видео, а потом удивляются, почему у них грид или тейбл тормозят, как отложения мамонта.
Почему во Vue все так просто и лаконично. Нужно действие - кидай в экшен, нужно вычисление + кэш - используй компьютед. В React такие сложности из колбека, мемо и рефов ... 🥲
Согласен, реакт запутанный и в нём есть высокий риск уронить производительность. А Свелте, как и вью, проще в этом плане. Вот доклад на эту тему czcams.com/users/livebB-R_lOlTLE?feature=share&t=744
согласен. В реакте на простейшие оптимизации надо тратить кучу времени, а во вью подход совершенно иной, там функции итак создаются 1 раз, поэтому ничего такого не надо.
@@PowWowVideo Согласен, хуков не много, но их часто используют для создания кастомных хуков, и потом с этим разбираться надо). Сложности в том что из коробки в React все таки меньше чем в том же Vue. Много нужно самому дописывать
Михаил, это были очень познавательные 8 минут)) Спасибо, наконец-то всё по полочкам с useCallback. На проектах все, в том числе я, его использовали неправильно.
Михаил, спасибо за видео. Как всегда на высоте. Сложные вещи простым языком. Было очень полезно послушать про правильное использование useCallback
Как всегда отлично! Спасибо! А еще я прям офигел насколько хороша новая дока React 😯
Михаил, спасибо вам за разъяснение useCallback, его лепят везде где нужно и не нужно и никто не понимает особо, зачем он нужен)) Теперь за 8 минут вашего видео все стало на свои места!! От вас контент просто бесценный!!))☺👍 Лайк однозначно!))
До этого видео я не мог понять для чего useCallback и как ей воообще пользоваться. Видео супер полезное. Частно тут нахожу что-то для себя, спасибо! (Самоучка)
Михаил, это огонь! У меня коллеги тоже любят обернуть банальное сравнение 2х переменных в мемоизацию, не парясь, что мемоизация сильно дороже элементарного сравнения 2х примитивов) нужен баланс между «я вообще ничего не знаю про мемоизацию» и «я мемоизирую каждый чих»
спасибо за сложные темы простым языком)
Спасибо Михаил! Полезное видео 👍
Очень полезный материал получился, спасибо!
Михаил как всегда отличное видео и понятное! Спасибо
доходчиво, спасибо за труды..
Просто супер доступно объяснил. Спасибо большое!!!
Отличное объяснение, спасибо!
отлично, очень ясное видение ситуации, спасибо!
Михаил, спасибо большое! Просто, понятно, интересно.
Спасибо большое за видео, очень качественно всё поясняется
Определенно отличное видео, спасибо!!
Михаил, спасибо большое! Смотрел твой бытрый курс по React Router, и тут после третьего видео CZcams "подсунул" мне это видео. Думал не смотреть, ведь "-да что я ещё могу узнать про useCallback?", оказалось, что ключевую вещь😅. Спасибо! Теперь буду тщательно думать перед решением мемоизации сущностей🤝
Михаил, спасибо за информацию!!!
Михаил, спасибо.
Всё просто и понятно !!!
"один мой коллега засунул целый реакт-компонент в useCallback" - ааааа!!! господи, я думал только у нас такая дичь в проекте) как же я устал бороться с этими мамкиными оптимизаторами) спасибо, теперь кроме видоса айти синяка, буду кидать еще ваш )
У ayub begimkulov тоже есть объяснение и оно несколько глубже даже чем тут )
Жёстко.
Вы, случайно, не вместе работаете?)
на 8:00 чуть оговорился "два кейса, когда нужен useEffect"
спасибо за видео!
Спасибо за объяснение!
Спасибо, все отлично объяснил
Привет, спасибо за видео! Наконец-то кто-то правильно объяснил, потому что все видео на эту тему содержат неправильную информацию и какие-то глупые надуманные примеры, не имеющие отношения к реальному миру.
Спасибо, наконец-то дошло, для чего этот хук нужен! Хотя второй вариант я использовала, благодаря подсказкам eslint(, но без понимания особого)
Большое спасибо:)
Кайф🎉 можно еще видео подробное по хукам?
Спасибо за пример про связку memo + useCallback. Такого даже чат GPT не подсказал)
Круто, можно про useMemo так же по полочкам разложить?)
Thanks Mihail!
Спасибо за видео
Супер, спасибо!
спасибо, очень понятно.
Михаил, вы создаете очень полезный контент)
дану нах...?))) а я не знал)
Ждем про useMemo)
Очень годно))
Спасибо!
Есть еще коллбэк-рефы, когда функция принимает как аргумент node (dom-узел) и присваивается атрибуту ref в JSX. Используется это обычно для передачи dom-узла кастомному хуку. useRef не всегда тут может помочь, ибо useEffect на него не реагирует, а вот коллбэк-реф он увидит.
Спасибо
Михаил, можешь сделать похожий обзор про useMemo? Понимаю, что там похожая ситуация, но всё же, возможно есть свои нюансы
Очень крутой 😎👍
Михаил, спасибо Вам за ваши труды!
С удовольствием смотрю Ваши курсы на Udemy.
Планируете ли Вы какой-нибудь новый курс?
Очень хотелось бы, раскрыть тему CI/CD Jenkins.
Приветствую.
В настоящий момент никакой конкретики по курсам нет. Есть мысли, идеи, но нет времени. По Дженкинсу в планах ничего не было.
Спасибо, но я ничего не понял. Можно ещё какой нибудь пример
Спасибо огромное, это лучшее объяснение useCallback во всех интернетах! Но я только одного не понял - зачем линтер требует добавить logUpdate в массив зависимостей во втором примере? Какая тут логика?
У нас в конторе принято всегда оборачивать. Я уже устал спорить, поэтому просто делаю че просят )) А в целом да, знаю давно, что это шляпа каждый раз мемоизировать. Еще есть другой фетишь: юзмемо. Каждую букву заворачивают 😅
Спасибо за ролик. Очень наглядное объяснение, ибо тема действительно непонятная. Полагаю, аналогичный подход актуален и для useMemo?
C useMemo чуть сложнее. Здесь мы просто создаем функцию, не вызывая ее. А useMemo предполагает мемоизацию вычислений. Поэтому иногда данный хук нам может пригодиться, чтобы не повторять дорогих вычислений, даже если мы не планируем передавать их в другой компонент. В целом, логика с memo и использованием массивов/объектов как зависимостей для других хуков - аналогичная. Но, повторюсь, есть и другие кейсы использования.
если можно о useEffect но с акцентом на помещение используемой в нем функции в массив зависимостей. линтер этого требует. но вот сегодня поместил и получил кольцевую обработку. как в видео. в случае когда мы не можем поместить функцию внутрь эффекта. например она вообще берется из собственного хука.
Забыли сказать про ментальную нагрузку) Минимальный оверхед который дает useCallback не стоит возможных проблем с производительностью в местах где забудешь обернуть в useCallback. Так что с практической точки зрения всё лепить в useCallback имеет смысл
господа, сколько не смотрел не могу понять разницу между useMemo, useEffect, useCallback. Даже после просмотра этого видео не до конца понял всю ситуацию с useCallback. Если не сложно, можете подробно разъяснить или скинуть ссылку на какой-то источник с подробным объяснением.
1е нормальное объяснеие🙏😀
4:17 говорится, что обновился родитель, но чей это родитель? этот момент не понятен, может кто объяснить?
отличный урок! Сам никогда не понимал толком, знал в теории, но на практике - профан, давай еще про useMemo, в чем разница с useCallback?
useCallback возвращает функцию, а useMemo возвращает уже готовое значение, например объект. А так, суть одна и та же - возвращать ссылку на одну и ту же сущность, если зависимости не изменились.
fantastic !
Михаил, вы волшебник. Я только учусь и вчера убил весь день на решение проблемы лишнего рендеринга. А тут ваш видосик подоспел как раз вовремя. Осталось придумать как это все состыковать с useForm :)) Спасибо вам большое за контент.
Сделай такой де пример, и предавай колбэк в таблицу и посмотри как будет рендерится или нет
Вопрос , а если мы данные вырисовываем с RTK query , то нужно ли использовать useCallback?
либо React query, там же по сути автоматом кешируется все
Что конкретно вы предлагаете кэшировать с useCallback при использовании названных библиотек?
пять лет уже постоянно что-то делаю на реакт но до этого материала до сих пор не дорос..
тупо лучший
Grand merci à vous, но обращаю внимание уважаемого автора на потенциальную оговорку 8:03: по всей видимости, вместо фразы "два кейса когда нам нужен useEffect()" имелось в виду "два кейса, когда нам нужен useCallback()"? Поправьте, если не так
Да, всё так.
Два кейса когда нужен useEffect (8:03) или всё же useCallback?
useCallback
видел как некоторые люди добавляют useCallback для callback отправленных в addEventListener, я так понимаю это излишне?
Излишне. Листнеры в таком варианте обычно добавляются в эффекте, внутри которого правильно будет и сам хэндлер создать.
👏👍
В первом случае хватило бы только React.memo, повторных ререндеров компоненты не происходило бы
Стоило сказать про преждевременную оптимизацию всё же. А то пойдут ведь добавлять useCallback+memo куда не попадя, считая, что так надо 😅
а если в Hook вынести?
spasibo
Спасибо, Михаил, у Вас наконец-то появились нормальные коллеги. Судя по объяснению данного хука в рамках курса по Реакт, достойных и мотивирующих коллег у Вас на тот момент не было!))
В смысле мотивирующих на подобный контент?))
@@mishanep Михаил, если я правильно понял предисловие, то до сегодняшнего дня у Вас были коллеги, твердо знавшие когда и в каких сочетаниях использовать useCallback))
8:02 useCallback*
В доке еще пишут можно все кастомные хуки в useCallback оборачивать
Оно там звучит примерно как "на всякий случай". Если команда небольшая и понятно как хуки будут использоваться, то оборачивать всё подряд было бы странно. Если пишем библиотеку, то уже выглядит логично.
Я без доки для себя взял это правило. На самом деле тут двояко.
Из плюсов - уменьшается ментальная сложность. Нам не нужно каждый раз заходить в хук и проверять, обернута ли функция, если мы ее используем в зависимостях в компоненте. Из минусов - уменьшается читаемость кода и увеличивается время написания. Немного увеличивается ментальная сложность при работе с хуком.
useCallback и memo - это не бесплатно, не факт, что в попытках оптимизации, всё не стало гораздо медленнее, чем без них. Нужны пруфы, пока же видно лишь то, что нет смысла использовать на столь легковесных компонентах лишнюю оптимизацию.
залогировал бы время отработки каждого из вариантов, иначе не очевидные у тебя утверждения на самом деле про скорость работы
База))
а как же removeEventListener, там необходимо передавать функцию с изначальной ссылкой, и соответственно для этого мы можем callback функцию, передаваемую в addEventListener обернуть в useCallback - чтобы не потерять ссылку на нашу изначальную callback функцию)
Смотря как вы добавляете, снимаете ивенты. Как правило, это одна и та же функция, обернутая в useEffect. А значит и ссылка на функцию будет одна.
Можно забить на useCallback, если ты передаешь свой колбек в какой-то самый простой компонент. Или когда данные, от которых он зависит, постоянно обновляются, и ты точно знаешь как он устроен внутри. А вот взаимодействие с DOM, это уже дорогая операция, это дороже чем инициализировать функцию, и чем 10 функций. А еще очень часто есть много готовых компонентов и компонентов из сторонних модулей, и как на это повлияет использование useCallback, заранее не известно. А выстрелить это может в самый неподходящий момент, заблокировать юзеру страницу, сожрать всю память или вылететь с переполнением стека вызовов. По этому, из соображений безопасности и здравого смысла, использовать useCallback надо для каждой объявленной внутри компонента функции, которая зависит от данных в этом компоненте. В противном случае ей там делать нечего, и она должна быть объявлена вне компонента.
спасибо очень полезная инфа что он юзается в тандеме с мемо
Ну вот эти слова про "дорогую операцию" ничем не подкрепленные, вообще не айс. Сам то проверял или так просто, услышал от кого-то, кто сам услышал от кого-то и т.д., и так вы просто повторяете бездумно друг за другом? Что там с holy js кстати, едешь/не едешь?
Типичное поведение практически всех современных программистов, в т.ч. высокого уровня - это слепое следование каким-либо догмам, не пытаясь разобраться, насколько они актуальны и в каких случаях. Туда же ничем не подкрепленные заявления о низкой / высокой производительности, бесконечная битва с ререндерами (в SPA), бОльшая часть которых на производительность с позиции end user влияет практически... никак.
А потом имеем глючное нечто типа сайта Озона (там Vue, но в данном случае это иррелевантно) с вот уже годами (периодически) отваливающейся фильтрацией.
Таковы реалии современного программирования "по фэн-шую".
Тут скорее дело не в том, дорогая операция или нет. Это в любом случае профилировать надо тогда.
Оптимизация просто не нужна, если нет видимых проблем с перформансом. А оптимизация не бесплатна больше в плане то, что мы пишем лишний код/обертки, увеличиваем ментальную сложность. Пускай мы даже ускорили работу компонента, если в реальном использовании этого не видно, это нет смысл.
Преждевременная оптимизация хуже чем никакая оптимизация вовсе.
Автору и некоторым комментаторам не мешало бы мат часть подтянуть. Не так страшен ререндер, сколько перемонтирование в дом. Вот так насмотрятся таких видео, а потом удивляются, почему у них грид или тейбл тормозят, как отложения мамонта.
Ролик может и неплохой, но без исходного текста не имеет никакого смысла. Дизлайк.
Почему во Vue все так просто и лаконично. Нужно действие - кидай в экшен, нужно вычисление + кэш - используй компьютед. В React такие сложности из колбека, мемо и рефов ... 🥲
Сам то же сравнивал и пришел к таким же выводам. Неоправданно все усложнено!!!
В реакте ТОЛЬКО 3-4 хука, которые надо заучить и правильно использовать и ВСЁ:) Какие сложности ?
Согласен, реакт запутанный и в нём есть высокий риск уронить производительность. А Свелте, как и вью, проще в этом плане. Вот доклад на эту тему
czcams.com/users/livebB-R_lOlTLE?feature=share&t=744
согласен. В реакте на простейшие оптимизации надо тратить кучу времени, а во вью подход совершенно иной, там функции итак создаются 1 раз, поэтому ничего такого не надо.
@@PowWowVideo Согласен, хуков не много, но их часто используют для создания кастомных хуков, и потом с этим разбираться надо). Сложности в том что из коробки в React все таки меньше чем в том же Vue. Много нужно самому дописывать