Это не умный инженер, а макака, которая не читает документацию и не интересуется как работает та или иная вещь, которой он пользуется. Просто фронтенд для домохозяек и васянов.
Почему так редко видео выходят, у тебя подача просто огонь, мозг прям сам запоминает твою информацию, обращение типо "ты понял" мне заходит сразу)) Хочется больше видео как минимум часовых и более
Что конкретно ты хотел проверить в Example1 (2:57)? Какая там могла быть разница, если ты рендерил оба варианта всего один раз? Разумеется, вычисление что с useMemo, что без него будет выполняться при первом рендере и время рендера будет +- одинаковым. Уже со второго рендера можно было бы проверять разницу - в компоненте с useMemo результат взялся бы из кеша, а в компоненте без useMemo вычислялся бы заново
Я тоже сначала возбудился на это. А потом обратил внимание на числа в профайлере. Там что-то порядка 3-4 мс. Ну, в офигенном случае будет 1 мс от использования юзмемо. И чо? Кто это заметит? )))
А стоит ли использовать юс мемо если например есть какие-то данные в переменной и из-за обновления пропсов происходит перерендер компонента и эта переменная с данными пересоздается лишний раз. А у нас на неё хук юс эффект навешен, например. Тогда юзать мемо ок?
3:20 Ты сравниваешь рендер с вычислениями, но фишка хука в мемоизации, а ты показываешь разницу на холодную загрузку И еще, из документации: If the overall logged time adds up to a significant amount (say, 1ms or more), it might make sense to memoize that calculation
вопрос в другом: если нет разницы, то оно точно работает так, как описано в ролике? ))) Ведь если там внутри суперсложная логика, то там, где оно "лишнее" - разве не должно работать ДОЛЬШЕ? Почему же оно одинаково? Может все-таки внутри у хуков есть оптимизация и они сами понимают что делать?
Может быть, это прозвучало в видео и я не заметил, но один из самых действенных способов это спросить себя: "выиграем ли мы от использования useMemo, с учетом, что нам нужно на каждый цикл (1) произвести вызов функции (это медленнее большинства операторов), (2) аллоцировать место под массив и заполнять его значением (послений аргумент useMemo)" - и если человек хоть сколько то понимает что такое память и принцип вызова функций, он достаточно просто сможет принимать решение о том нужно ли использовать useMemo
На мой взгляд упущено несколько важных деталей использования мемоизации от реакта* 1. PureComponents / React.memo() - Пропс пассинг в таких компонентах должен быть мемоизированным, в противном случае это просто не будет работать. 2. Почему то не учитывается сложность по памяти, ведь создание уймы ссылок на обьекты при вызове компонента так же не есть хорошо. 3. Использование мемоизации в больших контроллерах контекста или компонента (либо контейнерных компонентах)
5:40 в example6.jsx интересный момент: useMemo не просто бесполезен, в данонм случае он будет делать лишние рендеры компонента Header и div с children'ом, т.к. обновление идёт по userData. При этом если мы просто поместим этот же код (без фрагментов) на 21 строку, обновляться в случае изменения userData будет только один компонент Profile, что логично ведь это его пропс
реакт так не работает 1. useMemo - не реактивный хук. Хуки вызываются исключительно при рендере. Депсы хуков (useMemo, useEffect, useCallback) не являются реактивными триггерами их вызова, а лишь позволяют избегать вызовы коллбеков, переданных в эти хуки, при условии, что депсы не поменялись. Т.е. хуки будут вызываться ровно столько же раз, сколько рендеров произойдет в компоненте. Их колбеки будут соответственно вызываться тоже исключительно при рендере и при условии, что какой-то из депсов изменился 2. если ты засунешь хедер и див с чилдреном на 21 строку, то они будут перерендериваться при каждом рендере Layout. Если они останутся в useMemo, то они будут рендериться при каждом рендере, за вычетом тех рендеров, которые были проигнорированы с помощью useMemo. Т.е. этих рендеров может быть либо столько же, сколько и на 21 строке, либо меньше
@@messenja2547 изменение пропсов по умолчанию не влияет на рендер. Ререндер триггерится по сути одним действием - изменением состояния. При изменении состояния вызывается функция-компонент или метод render классового компонента, из-за чего вызывается рендер всех компонентов, которые рендерятся в них (потому что по сути JSX-верстка - это вызовы React.createElement, которые неизбежно вызываются, если вызвана функция, в которой эти вызовы расположены, т.е. наша функция-компонент или render метод). Т.е. если говорить изолированно о конкретном компоненте, то он рендерится по двум причинам - из-за изменения его состояния или из-за рендера родительского компонента (фактически же эта причина является следствием изменения состояния где-то выше в дереве) Если родительский компонент перерендерится, его дочерние компоненты перерендерятся вне зависимости от того, изменилсь их пропсы или нет. Это поведение можно изменить использованием React.memo. С его использованием по умолчанию пропсы будут сравниваться и повторный рендеринг будет происходить только при их изменении. Но это не то, как работает рендеринг в реакте, это мемоизация. Фактически рендер тригерится на этом хоке, а он уже, имея контроль над компонентом, который мы ему передали, своей внутренней логикой предотвращает его рендер и возвращает кеш.
Ну в 7:46 можно тоже без юзмемо, просто вынести в отдельный компонент счётчик Крч по моему опыту 99% использований юзмемо были из за неправильной организации структуры компонентов
Хорошо а как понять тогда, что компонент бы лучше оптимизировать одним из способов. Ведь у меня например он может не тормозить просто потому что хорошее железо.
Так: второй пример разберем. Сравнение, как мне кажется не корректное: нужно посмотреть сколько займет рендер компоненты с юз мемо, если ее вызовут второй и последующие разы с теми же параметрами. По идее в разы меньше, так как не будет вычисления. Если это бизнес кейс, то оптимизация нужна, нет?
оправдано ли использовать usememo для хранения найденного товара в корзине(500 товаров)? хотя без usememo не тормозит, но на всякий случай спрашиваю, вдруг операция поиска дорогая
в компонентах вообще не стоит логику поиска товара в корзине делать. Компоненты - это про UI, а не про данные и бизнес логику. Для таких вещей есть стейт менеджеры, в которых не возникает такого вопроса в принципе. не должны вычисления данных и бизнес логика зависить от рендеринга. Рендеринг должен зависеть от данных (поменялись нужные данные -> произошел рендеринг), а не наоборот (произошел рендеринг -> вычисляем данные) если же отвечать на этот конкретный вопрос, то "операция поиска", если речь идет о find - это цикл на 500 итераций. Скорее всего, это мелочь даже для телефонов. Хотя все зависит от количества рендеров этого компонента и логики в колбеке, передаваем в find (к примеру, там могут быть какие-то вложенные циклы или еще что-то)
Во втором примере если компонент будет рередериться то useMemo как раз таки необходим , так как без использования useMemo функция будет запускаться при каждом ререндере .
Да, функция будет запускаться, но ключевая идея в том чтобы мемоизировать именно сложные вычисления. В данных примерах идёт игра за миллисекунды перфоманса, где даже нет вложенных объектов, поэтому в подобных функциях следует избегать использования мемоизации
@@akichula так может свои тесты нужно проводить на жирных компонентах, как в реальной жизни, а не объявлять компонент, возвращать div и говорить, что разницы нет никакой? Полное отсутствие логики, что у тебя, что у автора.
На самом деле в некоторых моментах можно использовать useMemo если понимать как работает реакт. Не буду говорить за примеры, потому что не вижу полного кода приложения. Иногда выгоднее использовать useMemo с зависимостями чем лишний раз заставлять реакт что то перевычислять даже если ничего не лагает. Просто нужно иметь понимание для чего ты это делаешь. Так что Денис в чем то ты прав и в то же время не прав. Вот такая тавтология)
Автор, а пробовал ли ты в не пет проекте с большИм деревом вложенных компонентов сделать банальный console.log где то в глубине? Сколько будет его вызовов? Даже простые операции при большом их количестве будут существенно влиять на производительность. useMemo это способ заплатить озу вместо цпу. Так же странно что автор не видит смысл когда в deps передаётся не все что используется внутри хука. Вероятно результат не должен зависеть от того что не в deps, не?
Все, кроме 2:57, правильно. Остальное - оверхед, не дающий ничего. Мемоизировать булево выражение - это антипаттерн. Ты буквально на каждый рендер создаешь новый массив с зависимостями, вызываешь функцию useMemo, у тебя сравниваются депсы. Это явно медленнее, чем сразу же проверить что-то
Ты это я. За последние 6 лет я банально устал всем доказывать, что вот такая преждевременная оптимизация - полный треш. Разработчики реакт настолько насмотрелись на весь этот треш, что в 19ой версии ввели отдельный React Compiler для таких горе сеньоров.
Я иногда использую usememo как замену useeffect + usestate, что б код был более читаемый, но не уверен насколько страшно такое преступление, знатоки - просветите 🤔
Может это мидлы которые хорошо выучили теорию и решили много задачек на литкод и кодворсе, а самим кодом давно не занимались или просто джуны, в обличии мидлов и сеньйоров?
@@masserrackheim5358 громоздкость + сравнить несколько значений - это быстрее, чем создать массив депсов, сравнить его значения со старыми, вызвать функцию useMemo
Тут как бы вопрос: если рендер занимает одинаковое время С и БЕЗ useMemo, то возникает вопрос: а точно там мемо не нужен? Суть вот в чем: если внутри своя логика и бла-бла-бла, то ожидается, что будет с мемо работать ДОЛЬШЕ. Логично? Тогда почему работает одинаково? Может быть реакт сам внутри понимает уже сегодня надо или нет? А как раз в этом может и есть суть? Разрабы реакта говорят: оборачивайте ВСЕГДА, а мы сами внутри разберемся. Ну т.е. из этих же примеров видно, что разницы нет. Т.е. очевидно, что внутренняя логика этих хуков либо работает не так, как вы предполагаете, либо все же внутри есть оптимизация.
Я учу фронт, и боялся этих хуков (мемо и колбек), потому что не понимал куда их пхать, и соответственно игнорил их. Теперь понимаю, что делал все правильно :)
А я впервые столкнулся когда у меня хренова туча рендерингов вызывалось при переходе на след.пред страницу xD К тому времени я уже овладел более мене Redux)
Usememo не обязательно использовать для сложных вычислений. В некоторых случаях его использование может предотвратить вызов useffect при перерисовывании компонента. th-cam.com/video/GGo3MVBFr1A/w-d-xo.html
Как можно говорить, что случае сработала оптимизация и она маленькая, это не надо делать? Если в каждом месте делать оптимизацию рендеринга, то суммарно вырастет производительность. Давно не видел, чтобы была проблема с памятью, а не производительностью.
Какой кошмар, первые 6 примеров почему не стоит использовать usemamo про одно и тоже, и еще вставка мемасиков, еле дотерпел до когда нужно использовать. Теперь перейдем к примеру когда нужно использовать useMemo, Вы кэшируете компонент в зависимости от его пропсов, но это антипаттерн потому что для этого есть React.memo. Во вторый Вы используете редакс, да понимаю это просто потому что захотелось, но редакт тоже умеет кешировать и в этом случае кеширование лучше былобы сделать в редаксе, но это отдельная тема. Можно было просто сделать функцию которая требует сложных вычислений чтобы ничего не отвлекало. Посоветую во благо давний видос Айти синяк "Что вы знаете о useCallback?" про мемоизацию и его видос смотрится куда интереснее и там больше файктов, я не хочу чтобы вы его копировали просто он не повторяет одно и тоже по несколько раз, найдите свой путь, но именно этому видео не хватает технических фактов, и можно было свести к одной минуте. Я желаю Вам творческих успехов, но вот такое мое мнение о этом видео. Не в обиду!
Кэшировать компонент, простите, что за бред? Зачем. Когда надо было кэшировать логику расчёта. Хотя и согласен про React.memo, тут в тему всё же, но не useMemo же. А так useMemo используется не только для тяжёлых расчётов, но и временами приходится для компонентов принимающих объекты на вход. Приходится формирование объектов покрывать useMemo.
Ну вот, например, у меня есть контекст createContext({ scope: "" }), каждый роут получает этот контекст и оборачивает свои children в провайдер этого контекста, в зависимости от страницы в пропс value которого идет установка value={{ scope: "some_page" }}. Затем в навигации тупо { scope } = useContext(ScopeContext). Зачем здесь мемоизировать объект со скоупом?
@@masserrackheim5358 да на самом деле работаю на проекте, где ребята такую же чушь могут спокойно написать, у них хорошие зарплаты и лычки, так что верю, что код по мотивам реального. Он там просто странные вещи про сам реакт мемо говорил, как-то непрофессионально, как будто что-то понял, но вообще базово не понимает что такое сложность по памяти например.
посмотрел видео - почему ты говоришь мидлы /сеньры это все код джунов ? почему занижают планки и уже крепкий джун считается сеньером =_= из-за этого на рынке и блуждают псевдо сеньеры со знаниями джунов =)
Какие планки? Программирование - это не наука, а фронтенд область домохозяек. Соответственно соврать, что ты лев толстой, а на деле ***й простой не составляет труда при развитой метле и не очень шаристых типах, что тебя набирают. Объективных критериев кто хорош, а кто плох, нет.
Redux был реально лишний в твоем пример и к тому же еще функция вызовет повторный рендеринг. Не понял посыла зачем это нужно было, но скажу что сейчас есть более продвинутые, оптимзированные стейт менеджеры чем Redux. Пора уже отказаться от него.
useMemo не так сильно влияет на перформанс, если верить видео с разбором его под капотом. Так что если в команде принято мемоизировать все, то почему бы и нет? Я юзаю его как аналог computed во Vue, либо для графиков
дубль два написать комментарий (первый стёрт из-за вордфильтра на ссылки) @@moscowtv5767 вы бесконечно правы в этом утверждении. В свою очередь, я не смог найти такого в новой документации реакта (react 'точка' dev). Не ограничиваясь синтетическими примерами, сложно представить пример, когда useMemo будет реально экономить. Однако в документации написано следующее: "There is no significant harm to doing that either, so some teams choose to not think about individual cases, and memoize as much as possible" ([API] Reference -> useMemo -> "Should you add useMemo everywhere"). Это то, о чём я и говорю: если в команде есть обсессия на мемоизацию и производительность, всё же лучше придерживаться одного дизайна, useMemo не стоит так дорого. Тем не менее, есть кластер задач, где useMemo создает лишь дополнительную нагрузку. Например, когда в депенденсилисте все пропсы и всё состояние компонента. Замечу, что если в вычислении участвуют 1-2 пропса/стейта, которые меняются редко, из 5-6, и при этом остальные могут меняться часто, я бы всё же обернул такое вычисление в useMemo: это не будет противоречить гайдам из документации и здравому смыслу.
Если сеньор делает такие очевидные джуниорские ошибки, то возникает вопрос, а кто вообще назвал этого программиста сеньором? В моем понимании сеньор понимает, как работает фреймворк под капотом. Или нет?
@@ant3413 эмм, как бы нет. Как раз наоборот, если ты сеньор в какой-то технологии, то должен понимать, зачем ты используешь ту или иную функцию и как она работает, а не штамповать код на автомате. Зачем всё знать? Я разве это сказал? Но знать, как работает под капотом хук, который ты используешь, разве сеньор не должен? Или в чем тогда отличие мидла от сеньора?
@@batm1x но ты сейчас это говоришь, не ставь себя выше остальных....я тебе сказал уже что мы сеньер разработчики не углубляемся как под капотом работают хуки....и если ты думаешь что тем самым мы отличается от мидлов,то у тебя большие проблемы....
@@ant3413 так я и спрашиваю, чем тогда отличаетесь?))) Хорошо, уточню. Знать не в плане глубокого понимания технической реализации хука, а в плане понимания, чем хук занимается, как ведет себя в рантайме, на примере тех же мемоизирующих функций понимать целесообразность, опытный увидит, стоит ли кэшировать какие-то вычисления или дешевле по ресурсам просто каждый раз делать эти вычисления при рендере. Мне кажется в этом проявляется сеньор, из-за опыта он видит некоторые вещи более глубоко. Конечно углубляться в исходный код хуков не надо, но углубиться хотя бы до такого уровня, чтоб понимать, зачем ты это делаешь, а не делать просто на автомате, потому что ну вроде как так надо. Или поясни мне нормально отличия, а не говори про мои большие проблемы, я же серьезно спрашиваю
@@batm1x Давайте представим программиста в вакууме, работающего в конторе лет 5-7, который знает как работает проект, тянет джунов, понимает в ci/cd, в развёртывании приложений, в настройке nginx, постоянное общение с бэком и аналитическим/менеджерским составом, делегирует полномочия внутри коллектива и оперативно может подтянуть баги под конкретный дедлайн/релиз. Может ли условная контора считать по импакту, который он делает его синьором? Мне кажется - да. Причем, если перенести этого программиста в другую организацию, он никакой не синьор - на раскачку может уйти до полугода, чтобы он был столь же полезен. Если мы берём этого программиста и грейдим по вашему описанию - скорее он мидл. Вы, как мне кажется, описываете js инженера, который копает глубоко по хардам, этот человек точечно может хорошо улучшить и понять корень проблем, но не только в этом заключается синьёрность
"Возможно, самая распространенная ошибка умного инженера - оптимизировать то, чего не должно существовать" - Илон Маск
Это не умный инженер, а макака, которая не читает документацию и не интересуется как работает та или иная вещь, которой он пользуется. Просто фронтенд для домохозяек и васянов.
Как всегда топ, спасибо за твой труд, Дэнис. Хотелось бы больше контента на похожие темы, чтобы так сказать приблизить джунов к заветному званию мидл
Почему так редко видео выходят, у тебя подача просто огонь, мозг прям сам запоминает твою информацию, обращение типо "ты понял" мне заходит сразу)) Хочется больше видео как минимум часовых и более
Коммент для развития канала и персональной благодарности Дэну! Лайк - авансом.
Спасибо! Ты очень здорово объясняешь!
Очень доступно, спасибо!
Спасибо, за ценный совет!
Спасибо! очень полезно!
Нормально объяснил! Красава! Надеюсь, боли станет меньше
Что конкретно ты хотел проверить в Example1 (2:57)? Какая там могла быть разница, если ты рендерил оба варианта всего один раз? Разумеется, вычисление что с useMemo, что без него будет выполняться при первом рендере и время рендера будет +- одинаковым. Уже со второго рендера можно было бы проверять разницу - в компоненте с useMemo результат взялся бы из кеша, а в компоненте без useMemo вычислялся бы заново
Типичный тест от синьора-тимлида
Плюсую, очень странный тест. И спойлер: работать будет так же ибо автор забил на второй аргумент, а точнее там пустой массив.
тот же вопрос) рад что я не один, а то уже засомневался
Я тоже сначала возбудился на это. А потом обратил внимание на числа в профайлере. Там что-то порядка 3-4 мс. Ну, в офигенном случае будет 1 мс от использования юзмемо. И чо? Кто это заметит? )))
@@Fodintsov никто не замечает разницы и плюет на оптимизацию, а потом на проектах говнокоды
спасибо!👏👍
Изложение супер!
С возвращением
А стоит ли использовать юс мемо если например есть какие-то данные в переменной и из-за обновления пропсов происходит перерендер компонента и эта переменная с данными пересоздается лишний раз. А у нас на неё хук юс эффект навешен, например. Тогда юзать мемо ок?
3:20 Ты сравниваешь рендер с вычислениями, но фишка хука в мемоизации, а ты показываешь разницу на холодную загрузку
И еще, из документации:
If the overall logged time adds up to a significant amount (say, 1ms or more), it might make sense to memoize that calculation
вопрос в другом: если нет разницы, то оно точно работает так, как описано в ролике? ))) Ведь если там внутри суперсложная логика, то там, где оно "лишнее" - разве не должно работать ДОЛЬШЕ? Почему же оно одинаково? Может все-таки внутри у хуков есть оптимизация и они сами понимают что делать?
significant amount = 1ms? you mad bro?
@@KuruApni 🤣
@Archakov Blog, привет, можешь по-братски фиксануть демо pizza 2? Спасибо большое!
Многие забывают что результат кеширования и так надо где-то хранить, и оборачивать все в useMemo это только нагрузка
Может быть, это прозвучало в видео и я не заметил, но один из самых действенных способов это спросить себя: "выиграем ли мы от использования useMemo, с учетом, что нам нужно на каждый цикл (1) произвести вызов функции (это медленнее большинства операторов), (2) аллоцировать место под массив и заполнять его значением (послений аргумент useMemo)" - и если человек хоть сколько то понимает что такое память и принцип вызова функций, он достаточно просто сможет принимать решение о том нужно ли использовать useMemo
На мой взгляд упущено несколько важных деталей использования мемоизации от реакта*
1. PureComponents / React.memo() - Пропс пассинг в таких компонентах должен быть мемоизированным, в противном случае это просто не будет работать.
2. Почему то не учитывается сложность по памяти, ведь создание уймы ссылок на обьекты при вызове компонента так же не есть хорошо.
3. Использование мемоизации в больших контроллерах контекста или компонента (либо контейнерных компонентах)
1) Я бы добавил что не обязательно все стоит мемоизнуть, а только объекты, примитивы можно передавать как есть
можно использовать useMemo чтобы закешировать обьект, который вы передаете в другой компонент, чтобы не допустить лишних перерисовок того компонента
жаль что автор не раскрывает тему ререндора, а лишь вопрос кеширования вычислений
планируешь-лы видос про SEO optimization , Google search console
почему так часто пропадаешь?
5:40 в example6.jsx интересный момент:
useMemo не просто бесполезен, в данонм случае он будет делать лишние рендеры компонента Header и div с children'ом, т.к. обновление идёт по userData. При этом если мы просто поместим этот же код (без фрагментов) на 21 строку, обновляться в случае изменения userData будет только один компонент Profile, что логично ведь это его пропс
С каких пор изменение пропсов влияет на рендер?
@@QBasic60 не шути так
реакт так не работает
1. useMemo - не реактивный хук. Хуки вызываются исключительно при рендере. Депсы хуков (useMemo, useEffect, useCallback) не являются реактивными триггерами их вызова, а лишь позволяют избегать вызовы коллбеков, переданных в эти хуки, при условии, что депсы не поменялись. Т.е. хуки будут вызываться ровно столько же раз, сколько рендеров произойдет в компоненте. Их колбеки будут соответственно вызываться тоже исключительно при рендере и при условии, что какой-то из депсов изменился
2. если ты засунешь хедер и див с чилдреном на 21 строку, то они будут перерендериваться при каждом рендере Layout. Если они останутся в useMemo, то они будут рендериться при каждом рендере, за вычетом тех рендеров, которые были проигнорированы с помощью useMemo. Т.е. этих рендеров может быть либо столько же, сколько и на 21 строке, либо меньше
@@messenja2547 изменение пропсов по умолчанию не влияет на рендер. Ререндер триггерится по сути одним действием - изменением состояния. При изменении состояния вызывается функция-компонент или метод render классового компонента, из-за чего вызывается рендер всех компонентов, которые рендерятся в них (потому что по сути JSX-верстка - это вызовы React.createElement, которые неизбежно вызываются, если вызвана функция, в которой эти вызовы расположены, т.е. наша функция-компонент или render метод).
Т.е. если говорить изолированно о конкретном компоненте, то он рендерится по двум причинам - из-за изменения его состояния или из-за рендера родительского компонента (фактически же эта причина является следствием изменения состояния где-то выше в дереве)
Если родительский компонент перерендерится, его дочерние компоненты перерендерятся вне зависимости от того, изменилсь их пропсы или нет. Это поведение можно изменить использованием React.memo. С его использованием по умолчанию пропсы будут сравниваться и повторный рендеринг будет происходить только при их изменении. Но это не то, как работает рендеринг в реакте, это мемоизация. Фактически рендер тригерится на этом хоке, а он уже, имея контроль над компонентом, который мы ему передали, своей внутренней логикой предотвращает его рендер и возвращает кеш.
Ну в 7:46 можно тоже без юзмемо, просто вынести в отдельный компонент счётчик
Крч по моему опыту 99% использований юзмемо были из за неправильной организации структуры компонентов
Хорошо а как понять тогда, что компонент бы лучше оптимизировать одним из способов. Ведь у меня например он может не тормозить просто потому что хорошее железо.
Так: второй пример разберем. Сравнение, как мне кажется не корректное: нужно посмотреть сколько займет рендер компоненты с юз мемо, если ее вызовут второй и последующие разы с теми же параметрами. По идее в разы меньше, так как не будет вычисления. Если это бизнес кейс, то оптимизация нужна, нет?
да, в примере автора абсолютно бессмысленное сравнение, оно ничего не показывает
оправдано ли использовать usememo для хранения найденного товара в корзине(500 товаров)? хотя без usememo не тормозит, но на всякий случай спрашиваю, вдруг операция поиска дорогая
в компонентах вообще не стоит логику поиска товара в корзине делать. Компоненты - это про UI, а не про данные и бизнес логику. Для таких вещей есть стейт менеджеры, в которых не возникает такого вопроса в принципе.
не должны вычисления данных и бизнес логика зависить от рендеринга. Рендеринг должен зависеть от данных (поменялись нужные данные -> произошел рендеринг), а не наоборот (произошел рендеринг -> вычисляем данные)
если же отвечать на этот конкретный вопрос, то "операция поиска", если речь идет о find - это цикл на 500 итераций. Скорее всего, это мелочь даже для телефонов. Хотя все зависит от количества рендеров этого компонента и логики в колбеке, передаваем в find (к примеру, там могут быть какие-то вложенные циклы или еще что-то)
а ели у меня несколько хуков и каждую из них нужно сделать проверку, и при chenge одного, все хуки будут делать проверку
Во втором примере если компонент будет рередериться то useMemo как раз таки необходим , так как без использования useMemo функция будет запускаться при каждом ререндере .
Да, функция будет запускаться, но ключевая идея в том чтобы мемоизировать именно сложные вычисления. В данных примерах идёт игра за миллисекунды перфоманса, где даже нет вложенных объектов, поэтому в подобных функциях следует избегать использования мемоизации
@@akichula так может свои тесты нужно проводить на жирных компонентах, как в реальной жизни, а не объявлять компонент, возвращать div и говорить, что разницы нет никакой? Полное отсутствие логики, что у тебя, что у автора.
@@alexandrcorbin1709 вот я о том же
А вы ведете еще менторство по реакту?
На самом деле в некоторых моментах можно использовать useMemo если понимать как работает реакт. Не буду говорить за примеры, потому что не вижу полного кода приложения.
Иногда выгоднее использовать useMemo с зависимостями чем лишний раз заставлять реакт что то перевычислять даже если ничего не лагает. Просто нужно иметь понимание для чего ты это делаешь. Так что Денис в чем то ты прав и в то же время не прав. Вот такая тавтология)
Автор, а пробовал ли ты в не пет проекте с большИм деревом вложенных компонентов сделать банальный console.log где то в глубине? Сколько будет его вызовов? Даже простые операции при большом их количестве будут существенно влиять на производительность. useMemo это способ заплатить озу вместо цпу. Так же странно что автор не видит смысл когда в deps передаётся не все что используется внутри хука. Вероятно результат не должен зависеть от того что не в deps, не?
Все, кроме 2:57, правильно. Остальное - оверхед, не дающий ничего. Мемоизировать булево выражение - это антипаттерн. Ты буквально на каждый рендер создаешь новый массив с зависимостями, вызываешь функцию useMemo, у тебя сравниваются депсы. Это явно медленнее, чем сразу же проверить что-то
React конечно хорошо, но как насчет Flutter? Не планируешь чего-то нового?
Тоже слышал от одного разраба, что у них практически все обернули в usememo «на всякий случай»😅
Ты это я. За последние 6 лет я банально устал всем доказывать, что вот такая преждевременная оптимизация - полный треш. Разработчики реакт настолько насмотрелись на весь этот треш, что в 19ой версии ввели отдельный React Compiler для таких горе сеньоров.
😁
угар)
У тебя выбор: 20% производительности или 20% памяти. Что выберешь?
Я иногда использую usememo как замену useeffect + usestate, что б код был более читаемый, но не уверен насколько страшно такое преступление, знатоки - просветите 🤔
Я смотрю, не трогайте меня
Может это мидлы которые хорошо выучили теорию и решили много задачек на литкод и кодворсе, а самим кодом давно не занимались или просто джуны, в обличии мидлов и сеньйоров?
Парни, вопрос слегка не в тему. Но может кто-то сказать о минусах использования React.memo, иначе говоря, какова цена за его использование?
Минусов как таковых и нет. Используй просто по назначению.
В видео я объяснил в каких случаях. В остальных нет смысла
да никаких минусов нет кроме написания лишнего кода, автор просто контент из пальца высасывает как один лысый Бог ремонта.
@@masserrackheim5358 громоздкость + сравнить несколько значений - это быстрее, чем создать массив депсов, сравнить его значения со старыми, вызвать функцию useMemo
а еще я может пропустил - useMemo не всегда кэширует и может удалять кэш произвольно сам ( дока реакта ) подробнее описывать не буду)
да ты пропустил, что именно рассказывать не буду)
Тут как бы вопрос: если рендер занимает одинаковое время С и БЕЗ useMemo, то возникает вопрос: а точно там мемо не нужен? Суть вот в чем: если внутри своя логика и бла-бла-бла, то ожидается, что будет с мемо работать ДОЛЬШЕ. Логично? Тогда почему работает одинаково? Может быть реакт сам внутри понимает уже сегодня надо или нет? А как раз в этом может и есть суть? Разрабы реакта говорят: оборачивайте ВСЕГДА, а мы сами внутри разберемся. Ну т.е. из этих же примеров видно, что разницы нет. Т.е. очевидно, что внутренняя логика этих хуков либо работает не так, как вы предполагаете, либо все же внутри есть оптимизация.
Я учу фронт, и боялся этих хуков (мемо и колбек), потому что не понимал куда их пхать, и соответственно игнорил их. Теперь понимаю, что делал все правильно :)
А я впервые столкнулся когда у меня хренова туча рендерингов вызывалось при переходе на след.пред страницу xD
К тому времени я уже овладел более мене Redux)
Usememo не обязательно использовать для сложных вычислений. В некоторых случаях его использование может предотвратить вызов useffect при перерисовывании компонента. th-cam.com/video/GGo3MVBFr1A/w-d-xo.html
Ролик можно переименовать в - "Невыдуманные истории о которых невозможно молчать" :)
Ох уж эти синьоры, не знающие как работает useMemo. Я бы такого разработчика даже мидлом не назвал.
Как можно говорить, что случае сработала оптимизация и она маленькая, это не надо делать? Если в каждом месте делать оптимизацию рендеринга, то суммарно вырастет производительность. Давно не видел, чтобы была проблема с памятью, а не производительностью.
Преждевременная оптимизация никому никогда не помогала
Ого а ты уже сеньором стал ? )
конкистадором
насколько я знаю, давно уже, время не стоит на месте :)
@@ArchakovBlog герцогом
@@ArchakovBlog 😂😂😂
Какой кошмар, первые 6 примеров почему не стоит использовать usemamo про одно и тоже, и еще вставка мемасиков, еле дотерпел до когда нужно использовать. Теперь перейдем к примеру когда нужно использовать useMemo, Вы кэшируете компонент в зависимости от его пропсов, но это антипаттерн потому что для этого есть React.memo. Во вторый Вы используете редакс, да понимаю это просто потому что захотелось, но редакт тоже умеет кешировать и в этом случае кеширование лучше былобы сделать в редаксе, но это отдельная тема. Можно было просто сделать функцию которая требует сложных вычислений чтобы ничего не отвлекало. Посоветую во благо давний видос Айти синяк "Что вы знаете о useCallback?" про мемоизацию и его видос смотрится куда интереснее и там больше файктов, я не хочу чтобы вы его копировали просто он не повторяет одно и тоже по несколько раз, найдите свой путь, но именно этому видео не хватает технических фактов, и можно было свести к одной минуте. Я желаю Вам творческих успехов, но вот такое мое мнение о этом видео. Не в обиду!
Кэшировать компонент, простите, что за бред? Зачем. Когда надо было кэшировать логику расчёта. Хотя и согласен про React.memo, тут в тему всё же, но не useMemo же. А так useMemo используется не только для тяжёлых расчётов, но и временами приходится для компонентов принимающих объекты на вход. Приходится формирование объектов покрывать useMemo.
Ну вот, например, у меня есть контекст createContext({ scope: "" }), каждый роут получает этот контекст и оборачивает свои children в провайдер этого контекста, в зависимости от страницы в пропс value которого идет установка value={{ scope: "some_page" }}. Затем в навигации тупо { scope } = useContext(ScopeContext). Зачем здесь мемоизировать объект со скоупом?
"Абсолютно никто из них не задумывается" - ойли?)
Вроде чел хотел показать почему макаки на его проекте бездумно юзают функцию кэширования, но сам местами нанёс пурги.
скорее всего это код с каких нибудь курсов "войти в айти за неделю"
@@masserrackheim5358 да на самом деле работаю на проекте, где ребята такую же чушь могут спокойно написать, у них хорошие зарплаты и лычки, так что верю, что код по мотивам реального. Он там просто странные вещи про сам реакт мемо говорил, как-то непрофессионально, как будто что-то понял, но вообще базово не понимает что такое сложность по памяти например.
Они думают, что useMemo бесплатный, а он не бесплатный)
посмотрел видео - почему ты говоришь мидлы /сеньры это все код джунов ?
почему занижают планки и уже крепкий джун считается сеньером =_=
из-за этого на рынке и блуждают псевдо сеньеры со знаниями джунов =)
Какие планки? Программирование - это не наука, а фронтенд область домохозяек. Соответственно соврать, что ты лев толстой, а на деле ***й простой не составляет труда при развитой метле и не очень шаристых типах, что тебя набирают. Объективных критериев кто хорош, а кто плох, нет.
Redux был реально лишний в твоем пример и к тому же еще функция вызовет повторный рендеринг. Не понял посыла зачем это нужно было, но скажу что сейчас есть более продвинутые, оптимзированные стейт менеджеры чем Redux. Пора уже отказаться от него.
Почему пора?
useMemo не так сильно влияет на перформанс, если верить видео с разбором его под капотом.
Так что если в команде принято мемоизировать все, то почему бы и нет?
Я юзаю его как аналог computed во Vue, либо для графиков
"Эта оптимизация помогает избежать дорогостоящих вычислений при каждом рендере." - из документации. Ключевое слово найдите сами. :)
дубль два написать комментарий (первый стёрт из-за вордфильтра на ссылки)
@@moscowtv5767 вы бесконечно правы в этом утверждении. В свою очередь, я не смог найти такого в новой документации реакта (react 'точка' dev).
Не ограничиваясь синтетическими примерами, сложно представить пример, когда useMemo будет реально экономить. Однако в документации написано следующее: "There is no significant harm to doing that either, so some teams choose to not think about individual cases, and memoize as much as possible" ([API] Reference -> useMemo -> "Should you add useMemo everywhere"). Это то, о чём я и говорю: если в команде есть обсессия на мемоизацию и производительность, всё же лучше придерживаться одного дизайна, useMemo не стоит так дорого.
Тем не менее, есть кластер задач, где useMemo создает лишь дополнительную нагрузку. Например, когда в депенденсилисте все пропсы и всё состояние компонента.
Замечу, что если в вычислении участвуют 1-2 пропса/стейта, которые меняются редко, из 5-6, и при этом остальные могут меняться часто, я бы всё же обернул такое вычисление в useMemo: это не будет противоречить гайдам из документации и здравому смыслу.
аххаха
Очередная домохозяйка во фронтенде. Спасибо за экспертное мнение.
0:40 мидл тире сеньёр? На 6 строке вместо Link a href?
что тебя не устраивает? По твому в реакте есть компонент Link?
@@tonymonttana7 Перед тем, как писать такую дурь, ты хоть в гугл вбей запрос Link, NavLink...
Ну так мб это ссылка на внешний ресурс?
@@nomad5566 я не вижу в параметрах этого...
Чел ты...
Если сеньор делает такие очевидные джуниорские ошибки, то возникает вопрос, а кто вообще назвал этого программиста сеньором? В моем понимании сеньор понимает, как работает фреймворк под капотом. Или нет?
Что ты несешь ? ты думаешь что мы сеньеры всегда все на автомате делаем? мы все знакем как работает под капотом ? коммон,что за глупость....
@@ant3413 эмм, как бы нет. Как раз наоборот, если ты сеньор в какой-то технологии, то должен понимать, зачем ты используешь ту или иную функцию и как она работает, а не штамповать код на автомате. Зачем всё знать? Я разве это сказал? Но знать, как работает под капотом хук, который ты используешь, разве сеньор не должен? Или в чем тогда отличие мидла от сеньора?
@@batm1x но ты сейчас это говоришь, не ставь себя выше остальных....я тебе сказал уже что мы сеньер разработчики не углубляемся как под капотом работают хуки....и если ты думаешь что тем самым мы отличается от мидлов,то у тебя большие проблемы....
@@ant3413 так я и спрашиваю, чем тогда отличаетесь?))) Хорошо, уточню. Знать не в плане глубокого понимания технической реализации хука, а в плане понимания, чем хук занимается, как ведет себя в рантайме, на примере тех же мемоизирующих функций понимать целесообразность, опытный увидит, стоит ли кэшировать какие-то вычисления или дешевле по ресурсам просто каждый раз делать эти вычисления при рендере. Мне кажется в этом проявляется сеньор, из-за опыта он видит некоторые вещи более глубоко. Конечно углубляться в исходный код хуков не надо, но углубиться хотя бы до такого уровня, чтоб понимать, зачем ты это делаешь, а не делать просто на автомате, потому что ну вроде как так надо. Или поясни мне нормально отличия, а не говори про мои большие проблемы, я же серьезно спрашиваю
@@batm1x Давайте представим программиста в вакууме, работающего в конторе лет 5-7, который знает как работает проект, тянет джунов, понимает в ci/cd, в развёртывании приложений, в настройке nginx, постоянное общение с бэком и аналитическим/менеджерским составом, делегирует полномочия внутри коллектива и оперативно может подтянуть баги под конкретный дедлайн/релиз. Может ли условная контора считать по импакту, который он делает его синьором? Мне кажется - да. Причем, если перенести этого программиста в другую организацию, он никакой не синьор - на раскачку может уйти до полугода, чтобы он был столь же полезен.
Если мы берём этого программиста и грейдим по вашему описанию - скорее он мидл. Вы, как мне кажется, описываете js инженера, который копает глубоко по хардам, этот человек точечно может хорошо улучшить и понять корень проблем, но не только в этом заключается синьёрность