D
Лёгкая кастомизация, темизация
css-переменные бесплатны )
Size: a a a
2020 November 16
DS
css-переменные бесплатны )
Я понял что ты не имел дело с ui либами🌚
D
Прямо сейчас пишу одну
В
Интересно, не знал такой подход, спасибо
D
Я понял что ты не имел дело с ui либами🌚
Ну и да, много либ живёт без стайледов, а темизация через переменные или scss
V
Vladimir Samoilenko
Всем привет. Второй день плотно пытаюсь понять смысл useCallback и не понимаю. useMemo - понимаю, useCallback - нет. Закешировать значение функции для последующей быстрой выдачи, если аргументы не изменялись - понятно, а закешировать функцию-коллбек... извиняюсь, зачем? Во всякой доке пишут, чтобы ссылка на функцию не менялась, если не изменялось ничего из массива, что во втором аргументе. А зачем надо, чтобы ссылка на функцию не менялась, чтобы что? А если она изменится, что плохого произойдет?
На скриншоте код, скопированный мною из одного примера. Там два инпута, в первом из них значение переменной событием onChange устанавливается через useCallback, во втором - напрямую. Никакой разницы в работе двух этих инпутов нет от слова "вообще". Введенное значение одинаково бодренько отображается в <p> и в том, и в другом случае.
Если кому не лень пофилософствовать, помогите понять, плиз!
На скриншоте код, скопированный мною из одного примера. Там два инпута, в первом из них значение переменной событием onChange устанавливается через useCallback, во втором - напрямую. Никакой разницы в работе двух этих инпутов нет от слова "вообще". Введенное значение одинаково бодренько отображается в <p> и в том, и в другом случае.
Если кому не лень пофилософствовать, помогите понять, плиз!
Чтобы не ререндерился какой-нибудь memo компонент, как вариант
Либо если этот коллбэк - зависимость в юзэффекте каком-нибудь
Либо если этот коллбэк - зависимость в юзэффекте каком-нибудь
D
В смысле, я понимаю, о чём ты, но это не такой уж большой профит, мне кажется
NT
Vladimir Samoilenko
Всем привет. Второй день плотно пытаюсь понять смысл useCallback и не понимаю. useMemo - понимаю, useCallback - нет. Закешировать значение функции для последующей быстрой выдачи, если аргументы не изменялись - понятно, а закешировать функцию-коллбек... извиняюсь, зачем? Во всякой доке пишут, чтобы ссылка на функцию не менялась, если не изменялось ничего из массива, что во втором аргументе. А зачем надо, чтобы ссылка на функцию не менялась, чтобы что? А если она изменится, что плохого произойдет?
На скриншоте код, скопированный мною из одного примера. Там два инпута, в первом из них значение переменной событием onChange устанавливается через useCallback, во втором - напрямую. Никакой разницы в работе двух этих инпутов нет от слова "вообще". Введенное значение одинаково бодренько отображается в <p> и в том, и в другом случае.
Если кому не лень пофилософствовать, помогите понять, плиз!
На скриншоте код, скопированный мною из одного примера. Там два инпута, в первом из них значение переменной событием onChange устанавливается через useCallback, во втором - напрямую. Никакой разницы в работе двух этих инпутов нет от слова "вообще". Введенное значение одинаково бодренько отображается в <p> и в том, и в другом случае.
Если кому не лень пофилософствовать, помогите понять, плиз!
"А зачем надо, чтобы ссылка на функцию не менялась, чтобы что? А если она изменится, что плохого произойдет?"
надо, чтобы не создавать каждый раз новую функцию. Ты же обычно выносишь функции из какого-нибудь метода, а не хранишь их там, чтобы при вызове функции не создавалась новая функция?
надо, чтобы не создавать каждый раз новую функцию. Ты же обычно выносишь функции из какого-нибудь метода, а не хранишь их там, чтобы при вызове функции не создавалась новая функция?
VS
Vetro
Чтобы не ререндерился какой-нибудь memo компонент, как вариант
Либо если этот коллбэк - зависимость в юзэффекте каком-нибудь
Либо если этот коллбэк - зависимость в юзэффекте каком-нибудь
В смысле, если я пульну значение напрямую, то ререндериться будет все?
VS
"А зачем надо, чтобы ссылка на функцию не менялась, чтобы что? А если она изменится, что плохого произойдет?"
надо, чтобы не создавать каждый раз новую функцию. Ты же обычно выносишь функции из какого-нибудь метода, а не хранишь их там, чтобы при вызове функции не создавалась новая функция?
надо, чтобы не создавать каждый раз новую функцию. Ты же обычно выносишь функции из какого-нибудь метода, а не хранишь их там, чтобы при вызове функции не создавалась новая функция?
Ты про то, что при каждом новом рендере обработчики событий будут новыми функциями?
V
Vladimir Samoilenko
В смысле, если я пульну значение напрямую, то ререндериться будет все?
Если инлайн коллбэк генерится внутри рендера, и передается пропом в мемо компонент - ссылка будет изменяться каждый раз и мемо будет бесполезен (если не передана кастомная функция сравнения пропсов)
NT
Vladimir Samoilenko
Ты про то, что при каждом новом рендере обработчики событий будут новыми функциями?
по идеи да, новые ссылки будут
VS
по идеи да, новые ссылки будут
ну как бы и ладно, что плохого? Мусор в памяти?
NT
Vladimir Samoilenko
ну как бы и ладно, что плохого? Мусор в памяти?
ну если брать сообщение выше, то будет каждый раз ререндер потому что каждый раз будет создание нового обработчика и другая ссылка
VS
ну если брать сообщение выше, то будет каждый раз ререндер потому что каждый раз будет создание нового обработчика и другая ссылка
то есть, получается, что все обработчики ченджей, кликов и прочей хрени лучше оборачивать юзколлбеком?
NT
только там где нужно избежать какого-нибудь лишнего ререндера
NT
VS
только там где нужно избежать какого-нибудь лишнего ререндера
то есть, если обработчик внутренний, работает внутри компонента, то пусть себе так и работает, а если он передается пропсом куда-то вниз, то его лучше объюзколлбечить, чтобы ререндер происходил только при реальных изменениях? Примерно так?
D
Vladimir Samoilenko
то есть, получается, что все обработчики ченджей, кликов и прочей хрени лучше оборачивать юзколлбеком?
Да, это первая мысль, которая возникает, но на это обычно следующие ответы -
1) не стоит заниматься преждевременной оптимизацией
2) Реально это стоит делать, когда ты точно знаешь, что нижелещащий компонент мемоизирован, например
1) не стоит заниматься преждевременной оптимизацией
2) Реально это стоит делать, когда ты точно знаешь, что нижелещащий компонент мемоизирован, например
VS
Да, это первая мысль, которая возникает, но на это обычно следующие ответы -
1) не стоит заниматься преждевременной оптимизацией
2) Реально это стоит делать, когда ты точно знаешь, что нижелещащий компонент мемоизирован, например
1) не стоит заниматься преждевременной оптимизацией
2) Реально это стоит делать, когда ты точно знаешь, что нижелещащий компонент мемоизирован, например
а как можно мемоизировать целый компонент?