Видео супер подача бомба ✅👍 Жду видео про хук useReducer, useContext и ещё про кастомнык хуки. Пожалуйста выпусти эти видео. Ты прям инфу в голову как в коробку книги кладёшь))
Автор, спасибо тебе огромное!!! Кучу всего перечитал и пересморел по хукам, но ничего не понял пока не посмотрел твои видосы. Спасибище!!! Ты так доходчиво объясняешь, что все становится понятно сразу!
callback, который передается первым аргументом будет в любом случаем пересоздавать так же, как и депсы, в случае если депсы не изменились у нас будет возвращаться старая ссылка на эту функцию, то есть с предыдущего рендера
Всем по привету! Хорошее видео прям Минин второй :) Но один бы пример хоть где это нужно а где нет . Есть конечно догадки но на опыте еще не сталкивался .
Сам React должен делать ренедеры. Это необходимо делать только в крайних случаях, если хотите достичь производительности, а так пускай делает ререндеры. Как говориться в пределах разумного. Спасибо за информацию, было полезно
По поводу первого примера, а именно о том что "функция запоминает данные при маунте" стоило бы еще и добавить, что это не магия какая-то, а обычное замыкание. Функция замкнулась на данные из Lexical Environment функции App при первом вызове.
@@astkh4381 Арчаков ошибся в этот куске, когда обновляется компонент, все функции создаются заново и обработчик удаления скролла будет ссылаться не на старую ссылку, как он сказал, а на новую, а если мы удаляем новую ссылку на функцию hadleScroll, старая остается, соответсвенно и скролл останется
в этом примере нет необходимости использовать useCallback и memo в реальном проекте. это имеет смысла, если в дочерних компонентах большие вычисления. Это просто пример.
Продублирую вопрос, которые уже задавали, может ответит кто-то. Если все функции пересоздаются заново, то почему в stop не записывает ссылка на только созданную handleScroll?
Разве после ререндера в функции stop содержится предыдущий handleScroll? Она же тоже заново создаётся, соответственно и хэндлскролл в ней новый. А то что после изменения стэйта после вызова stop вызов хэндлскролл не прекращается, то это происходит вызов предыдущей функции, потому что она так и осталась, мы удалили подписку только на текущий хэндлскролл. Это можно проверить, добавив вывод в консоль стэйта
Годноту подвезли) Денис, сделай пожалуйста объясняющее видео по своей папке config, которую обычно используешь в проектах. Там много чего накручено, далеко не всё понятно для чего.
@Archakov Blog Привет! Спасибо больше за контент, очень доходчиво и без лишней воды! Очень жду от тебя, впрочем, наверное, как и многие тут, видео про useContext!) Планируешь ли записать его?
То, что ререндер - это норм и реакт всё разрулит - миф. Можете сравнить отзывчивость интерфейсов озона и яндекс маркета. В озоне используется вью, в котором по умолчанию всё мемоизировано (новые значения пропсов нужно отслеживать явно), а в яндексе любой неосторожный клик пораждает перерисовку всей страницы.
А все внутренние функции который пересоздаются и вызываются, к примеру та же функция Stop, раз она перевызвалась, то должна же тоже увидеть ссылку на новый скролл?
Хотел бы спросить: Правильно ли я понимаю - если есть дочерний компонент, ререндеры которого очень дорогостоящие, то, в таком случае, мы оборачиваем функцию, которую передаем в него, в useCallback. Вопрос вот в чем - допустим, в этот дочерний компонент мы передаем 5 функций. Если я не оберну хотя бы одну функцию в useCallback, то обернутые остальные 4 функции не имеют смысла(т к при ререндере родительского компонента, из которого мы эти функции передаем в дочерний, ререндерится эта одна единственная необернутая функция, что заставляет ререндерится дочерний компонент)? Заранее спасибо за ответ!
22:50 - из документации: «Этот метод предназначен только для оптимизации производительности. Не полагайтесь на него, чтобы «предотвратить» рендер, так как это может привести к ошибкам.»
Не понятно одно, почему применяя useCallback без зависимостей numbers остаётся неизменным, хотя это ссылка, а используя useRef меняется, хотя это тоже ссылка.
Спасибо за видео, но у меня есть вопрос: а почему нельзя просто функции onPlus и onMinus вынести за пределы компонента? Нам же нет смысла их каждый раз пересоздавать?
@@user-pd7kh1hw7c Но ведь функция "выше" компонента может как аргумент принимать сеттер из useState'а, и внутри вызывать этот сеттер :) Это все костыли и я не поддерживаю автора идеи вынести функции выше, но я сказал, что в принципе - это возможно)
@@ArchakovBlog Привет! Спасибо больше за контент, очень доходчиво и без лишней воды! Очень жду от тебя, впрочем, наверное, как и многие тут, видео про useContext!) Планируешь ли записать его?
Спасибо за уроки, одни из лучших на ютубе если не лучшие. Можно вопрос? Откуда английский акцент и странные фразочки типа "это есть неправильно"?))))) Мы так не говорим уже лет 100 или 200. Сейчас "это есть неправильно" значит что ты кушаешь то, что не положено))
Плохо на самом деле тем что вся эта мемоизация кушает оперативку. Все переменные колбека и зависимости хранится в памяти и для каждой завимости отдельный колбек. Да это также можно использовать для предотвращения многократного выполнения тяжелых операций но по факту это костыль для работы проверок идентичности у объектов и функций
Плохо в том случае, если мемоизировать все подряд. Даже если разраб будет оборачивать все мемоизировать, пользователь не заметит особых ухудшений производительности, просто, нет смысла. К счастью, браузер не выделяет 2мб памяти на вкладку
@@ArchakovBlog К сожалению в большинстве проектов я вижу что практически все обернуто в useCallback и useMemo, разрабы делают это даже просто на всякий случай. Вот и я стал постепенно привыкать к плохому) По сути если метод никуда не передается в пропсы и не содержит сайд эфектов мемоизация не нужна. Ну и кстати все зависит от того какими данными оперериует колбек если там например большой массив картинок в base64 формате обрабатывается то думаю браузер в кокой то момент подвиснет или выдаст ошибку интересно даже может эксперемент проведу как нибудь.
Ничего она не кушает. В случае с этими хуками -- кешируется только одно единственное значение, не считая легковесного массива зависимостей. Без мемоизации каждый рендер создает новую функцию, уничтожая старую, с мемоизацией дела обстоят даже проще -- не происходит лишняя аллокация памяти без необходимости, но размер памяти остается ровно таким же. Единственный случай, когда мемоизация играет плохую роль -- когда компонент уже вне зоны видимости, но на такие кейсы реакт умеет самостоятельно очищать закешированные значения, потому хуки мемоизации не работают на 100% надежно.
@@krolikrodjer8879 Ну то что для каждой зависимости это да я ошибся но как минимум в два раза больше памяти будут занимать все эти переменные. И насчет легковесности опять же все зависит от того что в зависимостях, хотя конечно использовать в качестве зависимостей что то кроме скалярных значений не совсем правильно но ничто не запрещает это делать и получается что по факту это не оптимизация а лишь вынужденная мера, чтобы избежать лишних рендеров
И еще не вижу проблемы в том что создается при каждом рендере новая функция. Это не более накладная операция чем создание и обслуживание мемоизованного стейта, проверки и апдейты этого стейта на каждом рендере
Мне кажется, что такие видео можно добавить в офф.документацию под каждую статью по хукам. Объяснение, как говорится, «на пальцах».
Видео супер подача бомба ✅👍
Жду видео про хук useReducer, useContext и ещё про кастомнык хуки.
Пожалуйста выпусти эти видео.
Ты прям инфу в голову как в коробку книги кладёшь))
Согласен с вами. Новые видео по хукам не помешают
Пожалуй лучший урок по useCallback в React
Автор, спасибо тебе огромное!!! Кучу всего перечитал и пересморел по хукам, но ничего не понял пока не посмотрел твои видосы. Спасибище!!! Ты так доходчиво объясняешь, что все становится понятно сразу!
Лучшее объяснение useCallback, спасибо за столь доскональное объяснение )
Спасибо за видео, ты очень круто объясняешь про хуки!
Денис, самые понятнее уроки по хукам, с нетерпения жду следующих видосов.
Мужик, это лучшее объяснение данного хука на просторах веб-паутины, спасибо!
единственный человек, у которого я увидел применение useCallback приближенное к реальности 👍
Божественная подача информации! Вот изза чего хочется ставить лайк и подписку
йоу, отличное видео, да и плейлист по хукам в принципе, продолжай пожалуйста. Хотелось бы посмотреть создание сайта с методологией MERN)
Я просто лайк зашел поставить, видос потом гляну, он точно топ, надо к нг закупиться еще
Сделай побольше видео про хуки. Круто и очень понятно объясняешь. Продолжай
А теперь добавь в этот плэй-лист видосик о кастомных хуках. Для полноты картины.
Лучший!!! Очень хорошо разжевываешь информацию!
Чудово пояснив! Я тепер розумію для чого потрібен цей useCallback
Минин в сравнении с тобой просто нервно курит в сторонке. Классно объясняешь, не прекращай!
Еееее, какая годнота) Пожалуйста, не записывай видео 3 часа ночи
Очень круто подаешь материал)
callback, который передается первым аргументом будет в любом случаем пересоздавать так же, как и депсы, в случае если депсы не изменились у нас будет возвращаться старая ссылка на эту функцию, то есть с предыдущего рендера
Спасибо тебе, Человечище!
Зубенко Михаил Петрович - МАФИОЗНИК
Всем по привету! Хорошее видео прям Минин второй :) Но один бы пример хоть где это нужно а где нет . Есть конечно догадки но на опыте еще не сталкивался .
Cупер! Спасибо большое за видео!
Сам React должен делать ренедеры. Это необходимо делать только в крайних случаях, если хотите достичь производительности, а так пускай делает ререндеры. Как говориться в пределах разумного. Спасибо за информацию, было полезно
Ух темп :) Спасибо! Можна дальше useContext/useReducer
По поводу первого примера, а именно о том что "функция запоминает данные при маунте" стоило бы еще и добавить, что это не магия какая-то, а обычное замыкание. Функция замкнулась на данные из Lexical Environment функции App при первом вызове.
можешь, пожалуйста, объяснить почему когда мы обновляем стейт, а вместе с ним функцию start, то start не обновляет ссылку на handleScroll?
@@astkh4381 Арчаков ошибся в этот куске, когда обновляется компонент, все функции создаются заново и обработчик удаления скролла будет ссылаться не на старую ссылку, как он сказал, а на новую, а если мы удаляем новую ссылку на функцию hadleScroll, старая остается, соответсвенно и скролл останется
Благодарю
Офигенно качественно и последовательно. Интересно какой у вас опыт ?
в этом примере нет необходимости использовать useCallback и memo в реальном проекте. это имеет смысла, если в дочерних компонентах большие вычисления. Это просто пример.
Продублирую вопрос, которые уже задавали, может ответит кто-то.
Если все функции пересоздаются заново, то почему в stop не записывает ссылка на только созданную handleScroll?
Разве после ререндера в функции stop содержится предыдущий handleScroll? Она же тоже заново создаётся, соответственно и хэндлскролл в ней новый. А то что после изменения стэйта после вызова stop вызов хэндлскролл не прекращается, то это происходит вызов предыдущей функции, потому что она так и осталась, мы удалили подписку только на текущий хэндлскролл. Это можно проверить, добавив вывод в консоль стэйта
Годноту подвезли) Денис, сделай пожалуйста объясняющее видео по своей папке config, которую обычно используешь в проектах. Там много чего накручено, далеко не всё понятно для чего.
молодец!
А почему конда start пересоздается, не начинает работать с тоже пересозданным handleClick-oм, а все равно ссылается на старый?
Начинает, но стоп уже не ссылается на старый листенер, поэтому стартовать то новый евент линтенер стартует, а вот старый евент не стопится уже
@Archakov Blog Привет! Спасибо больше за контент, очень доходчиво и без лишней воды! Очень жду от тебя, впрочем, наверное, как и многие тут, видео про useContext!) Планируешь ли записать его?
То, что ререндер - это норм и реакт всё разрулит - миф. Можете сравнить отзывчивость интерфейсов озона и яндекс маркета. В озоне используется вью, в котором по умолчанию всё мемоизировано (новые значения пропсов нужно отслеживать явно), а в яндексе любой неосторожный клик пораждает перерисовку всей страницы.
Надо добавить что на практике создавать ивент листенер таким образом не надо, только использовать ивенты реакта
Я ПОНЯЛ!!!
🔥🔥🔥🔥🔥🔥🔥
Получается useCallback замыкает в себе старое лексическое окружение?
А все внутренние функции который пересоздаются и вызываются, к примеру та же функция Stop, раз она перевызвалась, то должна же тоже увидеть ссылку на новый скролл?
Хотел бы спросить:
Правильно ли я понимаю - если есть дочерний компонент, ререндеры которого очень дорогостоящие, то, в таком случае, мы оборачиваем функцию, которую передаем в него, в useCallback. Вопрос вот в чем - допустим, в этот дочерний компонент мы передаем 5 функций. Если я не оберну хотя бы одну функцию в useCallback, то обернутые остальные 4 функции не имеют смысла(т к при ререндере родительского компонента, из которого мы эти функции передаем в дочерний, ререндерится эта одна единственная необернутая функция, что заставляет ререндерится дочерний компонент)? Заранее спасибо за ответ!
видос идет 25 мин с темой useCallback, но при этом посвятили ему тут минут 5 максимум
Можно же заместо prev[prev.length - 1] + 1 просто написать prev.length : ?
Это частный случай, подойдет для [1,2,3,4,5], но не подойдет например для [2,3,4,5].
22:50 - из документации: «Этот метод предназначен только для оптимизации производительности. Не полагайтесь на него, чтобы «предотвратить» рендер, так как это может привести к ошибкам.»
Спасибо!!!
Не понятно одно, почему применяя useCallback без зависимостей numbers остаётся неизменным, хотя это ссылка, а используя useRef меняется, хотя это тоже ссылка.
Зачем хэндлер делать через eventListener если можно через пропсу. Или это как пример?
👍👍👍👍👍👍👍
Спасибо за видео, но у меня есть вопрос: а почему нельзя просто функции onPlus и onMinus вынести за пределы компонента? Нам же нет смысла их каждый раз пересоздавать?
они использую локальный стейт компонента, следовательно, не будут работать "выше" компонента)
@@user-pd7kh1hw7c Но ведь функция "выше" компонента может как аргумент принимать сеттер из useState'а, и внутри вызывать этот сеттер :)
Это все костыли и я не поддерживаю автора идеи вынести функции выше, но я сказал, что в принципе - это возможно)
Модель своей клавиатуры не подскажешь? Больно клёва звучит она.
Varmilo VA87MN
сделайте видео об "Axios"
А в чем прикол useCallback, если есть useRef, в котором мы можем сохранить функцию?
Привет. Спасибо за контент. Вопрос, это последнее видео серии про хуки?
Привет! Не-а
@@ArchakovBlog Привет! Спасибо больше за контент, очень доходчиво и без лишней воды! Очень жду от тебя, впрочем, наверное, как и многие тут, видео про useContext!) Планируешь ли записать его?
какая у тебя тема в VSC и спасибо за уроки
Коммент просто
Button- су , плевать - сохранились у вас ссылки или нет :D
Если все функции пересоздаются заново, то почему в stop не записывает ссылка на только созданную handleScroll
Тоже не понимаю
Спасибо за уроки, одни из лучших на ютубе если не лучшие. Можно вопрос? Откуда английский акцент и странные фразочки типа "это есть неправильно"?))))) Мы так не говорим уже лет 100 или 200. Сейчас "это есть неправильно" значит что ты кушаешь то, что не положено))
✅ - это какая то библиотека?
Ужос! И это только с тремя кнопками! Такой гемор😊 А что будет в случае интернет магазина😮
Плохо на самом деле тем что вся эта мемоизация кушает оперативку. Все переменные колбека и зависимости хранится в памяти и для каждой завимости отдельный колбек. Да это также можно использовать для предотвращения многократного выполнения тяжелых операций но по факту это костыль для работы проверок идентичности у объектов и функций
Плохо в том случае, если мемоизировать все подряд. Даже если разраб будет оборачивать все мемоизировать, пользователь не заметит особых ухудшений производительности, просто, нет смысла. К счастью, браузер не выделяет 2мб памяти на вкладку
@@ArchakovBlog К сожалению в большинстве проектов я вижу что практически все обернуто в useCallback и useMemo, разрабы делают это даже просто на всякий случай. Вот и я стал постепенно привыкать к плохому) По сути если метод никуда не передается в пропсы и не содержит сайд эфектов мемоизация не нужна. Ну и кстати все зависит от того какими данными оперериует колбек если там например большой массив картинок в base64 формате обрабатывается то думаю браузер в кокой то момент подвиснет или выдаст ошибку интересно даже может эксперемент проведу как нибудь.
Ничего она не кушает. В случае с этими хуками -- кешируется только одно единственное значение, не считая легковесного массива зависимостей. Без мемоизации каждый рендер создает новую функцию, уничтожая старую, с мемоизацией дела обстоят даже проще -- не происходит лишняя аллокация памяти без необходимости, но размер памяти остается ровно таким же. Единственный случай, когда мемоизация играет плохую роль -- когда компонент уже вне зоны видимости, но на такие кейсы реакт умеет самостоятельно очищать закешированные значения, потому хуки мемоизации не работают на 100% надежно.
@@krolikrodjer8879 Ну то что для каждой зависимости это да я ошибся но как минимум в два раза больше памяти будут занимать все эти переменные. И насчет легковесности опять же все зависит от того что в зависимостях, хотя конечно использовать в качестве зависимостей что то кроме скалярных значений не совсем правильно но ничто не запрещает это делать и получается что по факту это не оптимизация а лишь вынужденная мера, чтобы избежать лишних рендеров
И еще не вижу проблемы в том что создается при каждом рендере новая функция. Это не более накладная операция чем создание и обслуживание мемоизованного стейта, проверки и апдейты этого стейта на каждом рендере
Всё таки не показал примерами, когда не рекомендуется использовать usecallback
Не React всё таки, конченная вещь.
Vue рулит
@@miloman1995s он реактивен.
Напиши не конченую вещь, человечество ждёт
@@andTutin ты не понимаешь шуток? иди учись в свой гигбрейнс дитя.
откуда столько злости (
действием очистки консоли ждать отвязки события...