Size: a a a

JavaScript.Ninja

2021 April 19

VN

Vladislav Navrocky in JavaScript.Ninja
спасибо 🙂
источник

YS

Yuri Strelets in JavaScript.Ninja
ну перерендерится он все равно, но до дома изменения не дойдут
источник

AI

Arthur Irgashev in JavaScript.Ninja
а, блин, ток щас заметил, что написал
источник

AI

Arthur Irgashev in JavaScript.Ninja
соррян, уже идти спать пора )
источник

AI

Arthur Irgashev in JavaScript.Ninja
@AntonuKor, я чёт поплыл и перепутал всё, что можно было. начал про рендеры, мысленно закончил фазой коммита
источник

AK

Anton Kalodzich in JavaScript.Ninja
Так а если перерендрится все равно, то в чем смысл useCallback тогда?
источник

YS

Yuri Strelets in JavaScript.Ninja
та по коду только смотреть, как правило сторонние либы не мемоизируют компоненты которые торчат наружу, а компоненты в проекте надо смотреть, да и обмазывать все мемоизацией не есть гуд, т.к. мемоизация может стоить дороже, чем реакт перерендерит свое виртуальное дерево, по факту в дом изменения не будут запушены
источник

YS

Yuri Strelets in JavaScript.Ninja
например есть какой-то сложный компонент который есть смысл обернуть в мемо, и вот в него надо будет пропсы функции заворачивать в useCallback, чтобы сократить нежелательные "тяжелые" ререндеры
источник

AI

Arthur Irgashev in JavaScript.Ninja
строго говоря, есть минимум три кейса, когда компонент апдейтится
1) пропсы изменились
2) стейт изменился
3) у родителя вызвался render
(может что-то ещё, но сейчас уже не вспомню, лучше завтра)

и вот для защиты ре-рендера дочерних компонентов лучше чилды оборачивать в мемо / писать scu. коллбеки могут быть полезны в нескольких случаях:
1) в теле коллбека есть какие-то затратные вычисления
2) от них зависят другие вычисления
3) ты передаёшь ссылки в дочерние компоненты

по п.3 - даже если там будет memo, то при получении новой ссылки он начнёт делать апдейт, т.к. пропсы были изменены. мемоизация в этом случае может помочь убрать ссылочное неравенство в пропсах
источник

AI

Arthur Irgashev in JavaScript.Ninja
тут под каждым словом подписываюсь
источник

YS

Yuri Strelets in JavaScript.Ninja
да и в зависимости от задачи memo можно заменить на useMemo
источник

AI

Arthur Irgashev in JavaScript.Ninja
но чаще всего на это всё можно просто забить (на все эти memo / SCU), т.к. это всё уже специфичные инструменты, к-е преждевременно применять не стоит
источник

AK

Anton Kalodzich in JavaScript.Ninja
Так useCallback же мемоизирует саму функцию, как на вычисления в теле он может повлиять?
источник

YS

Yuri Strelets in JavaScript.Ninja
в теле дочернего компонента может)
источник

AI

Arthur Irgashev in JavaScript.Ninja
да
источник

AI

Arthur Irgashev in JavaScript.Ninja
ну и само создание useCallback может быть затратным, в зависимости от кода
источник

AK

Anton Kalodzich in JavaScript.Ninja
А раз получается, что все в общем-то сводится к memo/SCU, то единственный способ понять, мемоизирован ли дочерний компонент - посмотреть в его код? Как-то нарушается идея сокрытия. Получается, что до конца нельзя кзнать публичный апи не посмотрев в исходники
источник

AK

Anton Kalodzich in JavaScript.Ninja
Можете пояснить?
источник

YS

Yuri Strelets in JavaScript.Ninja
надо понимать что функциональный компонент реакта это просто функция, которая выполняется на каждом рендере, соответственно пересоздавая все переменные, функции и проч, поэтому и существуют useRef, useMemo, useCallback, чтобы сохранить ссылку между перерендерами
источник

AK

Anton Kalodzich in JavaScript.Ninja
Да, это я понимаю. Но не понимаю, как мемоизация самой функции через useMemo влияет на выполнение затратных вычислений в теле этой функции
источник