не понимаю. useMemo - понимаю, useCallback - нет. Закешировать значение функции для последующей быстрой выдачи, если аргументы не изменялись - понятно, а закешировать функцию-коллбек... извиняюсь, зачем? Во всякой доке пишут, чтобы ссылка на функцию не менялась, если не изменялось ничего из массива, что во втором аргументе. А зачем надо, чтобы ссылка на функцию не менялась, чтобы что? А если она изменится, что плохого произойдет?
На скриншоте код, скопированный мною из одного примера. Там два инпута, в первом из них значение переменной событием onChange устанавливается через useCallback, во втором - напрямую. Никакой разницы в работе двух этих инпутов нет от слова "вообще". Введенное значение одинаково бодренько отображается в <p> и в том, и в другом случае.
Если кому не лень пофилософствовать, помогите понять, плиз!
Чтобы не ререндерился какой-нибудь memo компонент, как вариант Либо если этот коллбэк - зависимость в юзэффекте каком-нибудь
"А зачем надо, чтобы ссылка на функцию не менялась, чтобы что? А если она изменится, что плохого произойдет?" надо, чтобы не создавать каждый раз новую функцию. Ты же обычно выносишь функции из какого-нибудь метода, а не хранишь их там, чтобы при вызове функции не создавалась новая функция?
В смысле, если я пульну значение напрямую, то ререндериться будет все?
Ты про то, что при каждом новом рендере обработчики событий будут новыми функциями?
Если инлайн коллбэк генерится внутри рендера, и передается пропом в мемо компонент - ссылка будет изменяться каждый раз и мемо будет бесполезен (если не передана кастомная функция сравнения пропсов)
по идеи да, новые ссылки будут
ну как бы и ладно, что плохого? Мусор в памяти?
ну если брать сообщение выше, то будет каждый раз ререндер потому что каждый раз будет создание нового обработчика и другая ссылка
то есть, получается, что все обработчики ченджей, кликов и прочей хрени лучше оборачивать юзколлбеком?
Да, это первая мысль, которая возникает, но на это обычно следующие ответы - 1) не стоит заниматься преждевременной оптимизацией 2) Реально это стоит делать, когда ты точно знаешь, что нижелещащий компонент мемоизирован, например
а как можно мемоизировать целый компонент?
React.memo(component)
а, это что-то устаревшее классовое?
ок, значит, надо почитать.
ну есть же примерно React.PureComponent
Нууу, это как раз для классовых
Обсуждают сегодня