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