Что выбрать: глобальные переменные или useThis()?

[@ITKAMASUTRA]

Очень крутые видео на канале, структурированность, подача, анимации - всё на высоте! ✊

[@it-sin9k]

Спасибо!) Мы очень стараемся)

[@muratx10]

Спасибо за полезный контент. 🔥

[@it-sin9k]

Всегда к вашим услугам)

[@spoonjeee4785]

Спасибо!

[@АнатолийГорбов-о1ь]

Согласен, отличный канал, очень много полезного и интересного!

[@НикитаГончаров-е8ш]

Огонь🔥🔥🔥

[@vitaliyyasinskiy3689]

1:31 а разве синтаксис spread на 12 строке в данном случае не будет вызывать лишние ререндеры? Ведь spread всегда возвращает новый массив

[@mikhailstepanischev8316]

Класс,спс !

[@serhiiazizov2303]

Спасибо большое за проделанную работу. В вашем случае можно через переменную вместо useRef. export default () => { let timeout = null; const onClick = () => clearTimeout(timeout); useEffect(() => { timeout = setTimeout(() => { console.log('===>') }, 3000); }, []); return stop timer }

[@it-sin9k]

Почти могу согласиться. Представьте, что произошел render, вызвался useEffect, в переменную timeout положили timeoutId. И действительно при клике timeout очистился бы. НО допустим за эти 3 секунды по какой то другой причине произошел render. Это значит, что создалась новая переменная timeout, заново создался onClick завязанный уже на новый timeout и передался в button. А ссылка на старый timeoutId будет утеряна. И если пользователь нажмет после рендера на кнопку, тогда старый timeout не очиститься и setTimeout отработает. Поэтому такой способ крайне рискованный. Лучше использовать useRef

[@serhiiazizov2303]

@@it-sin9k согласен. Спасибо.

[@VeaceslavBARBARII]

зис - zees вис/вьэс - this виз - these уиз - whiz Cпасибо за видео.

[@cikada3398]

лайк не глядя

[@it-sin9k]

но лучше все таки посмотреть))))

[@sergeykhairulin]

1:14 почему в setStateCounter передается стрелочная функция, а не просто значение stateCounter+1 ? Так тоже можно делать?

[@it-sin9k]

Да, можно делать. Я не помню почему такой синтаксис выбрал честно говоря, но разницы никакой нет)

[@aboba86468]

​@@it-sin9k А точно нет разницы? Ведь в самой доке по useState приведён именно такой пример с функцией, которая принимает prevState. Как я понимаю это нужно из-за того, что setState асинхронный, и никогда нельзя доверять предыдущему значению вот так просто напрямую. Хз, может, если мы больше нигде не изменяем это значение, то разницы никакой. Но для меня не проблема написать чуть лишнего, предохранив себя от трудновоспроизводимых багов. Если я не прав, и есть какое-то чёткое объяснение, то тыкните плз)

[@avisalon4730]

Круть!

[@it-sin9k]

Спасибо!)

[@la-vallet]

В одном из предыдущих видео говорилось, что планируется тема о UiKIt. Можно ли её ожидать в ближайшем времени? Было бы очень интересно) Спасибо за Ваши видео!

[@it-sin9k]

у нас была проба одно видео, перевести тему с js на работу с темизацией, kzbin.info/www/bejne/bam7dX-cnMRgh80 судя по количеству просмотров люди не захотели смотреть

[@trustlang_ua]

давай видос про глобальный стейт (redux, mobx, effector etc) и что лучше для чего подходит

[@it-sin9k]

Спасибо, что оставляете комментарии!) Запросов достаточно много, на разные тему, поэтому в твитере я устраивал голосовалку, где собрал разные темы, которые можно было бы раскрыть) И после окончания темы хуков, мы перейдем на патерны. А потом снова устроим голосовалки уже только в youtube и в твитере, сумируем голосва)

[@trustlang_ua]

@@it-sin9k спасибо за ответ)

[@g0ld3nsecr3t6]

Обычно с timeout я использовал useState, где [timeout] = useState({value: null})

[@it-sin9k]

надеюсь теперь будете использовать useRef() :)

[@g0ld3nsecr3t6]

@@it-sin9k , но и моё решение имеет право на существование, верно?) Стало любопытно, т.к вы упомянули слово "надеюсь" :)

[@it-sin9k]

я какое-то время назад уже принял, что большинство решений имеют право на жизнь) Просто в одном решении у тебя одни преимущества и недостатки, а в другом другое) Почему я бы не пользовался вашим решением, это потому что state если передавать через props, и timeout значение изменится, в таком случае вы получите рендеры дополнительные) В случае с ref вы не получите дополнительные рендеры) для меня это важно и поэтому я бы не стал использовать) но это маловероятно, что вы почувствуете просадку по перфомансу) поэтому в рамках сайтах всем без разницы такие мелкие экономии))

[@-X-Ray-]

Сколько же тайн хранит react :)

[@it-sin9k]

Мы постараемся еще парочку раскрыть)

[@-X-Ray-]

@@it-sin9k буду с нетерпением ждать)

[@andTutin]

А в чем тайна ?

[@Shperung]

Дякую вельми корисно

[@nikitakurochka2752]

А есть в планах записать урок по поводу react portal ?

[@it-sin9k]

хмм, а что именно непонятно в портале? Принцип его работы? Способы использования?

[@nikitakurochka2752]

@@it-sin9k Как его можно красиво применять)

[@it-sin9k]

спасибо за комментарий, я подумаю пособираю еще отзывы)

[@bakaleisanich]

а можно сразу делать так? let type = useRef('').current и потом сразу присваивать так type = ...

[@it-sin9k]

Можно так делать, но есть пара нюансов. Если ты хочешь пробрасывать child компоненту это значение, а он memo компонент, тогда ты можешь вызвать дополнительные рендеры. Тоже самое и с хуками, если ты используешь useEffect и внутри будешь использовать такой type. Тогда eslint правило будет просить добавить такой type в зависимости, а если бы ты не достал сразу значение, то не просил бы. Поэтому, чтобы не встревать в такие ситуации я для себя решил, не использовать такой синтаксис