#урок дня
Дэн Абрамов в своей статье о хуках в React говорит нам: «Не врите Реакту о зависимостях хука, указывайте все».
ESlint вторит ему: Этот код нужно исправить.
Но я же умный и без сопливых знаю точные зависимости, поэтому:
// eslint-disable-next-line react-hooks/exhaustive-deps
Мой UI тем временем ведёт себя вот так…
P. S. обратили внимание на ссылку с подсветкой текста? Завтра будет фишка по этому поводу.
P. P. S. Перевод статьи доступен на Хабре, но учтите, что материала там минут на сорок, на любом языке: https://m.habr.com/en/company/ruvds/blog/445276/
#react #hooks #useeffect #eslint
Дэн Абрамов в своей статье о хуках в React говорит нам: «Не врите Реакту о зависимостях хука, указывайте все».
ESlint вторит ему: Этот код нужно исправить.
Но я же умный и без сопливых знаю точные зависимости, поэтому:
// eslint-disable-next-line react-hooks/exhaustive-deps
Мой UI тем временем ведёт себя вот так…
P. S. обратили внимание на ссылку с подсветкой текста? Завтра будет фишка по этому поводу.
P. P. S. Перевод статьи доступен на Хабре, но учтите, что материала там минут на сорок, на любом языке: https://m.habr.com/en/company/ruvds/blog/445276/
#react #hooks #useeffect #eslint
#видео дня
Хук useEffect в React с самого начала был как микроскоп, который работал и выглядел как кувалда. Потому его и используют как кувалду даже там, где нужен микроскоп.
React 18 принёс ещё больше вопросов (отчасти ещё и потому, что документация сильно отстаёт и изначально неверна).
Так что я, конечно, настоятельно рекомендую почитать Дэна Абрамова: https://overreacted.io/a-complete-guide-to-useeffect/
Есть в переводе на Хабре: https://habr.com/ru/company/ruvds/blog/445276/
А чтобы добить знания — глянуть видео о useEffect и его современном значении и правильном применении: https://www.youtube.com/watch?v=HPoC-k7Rxwo
#react #hooks #useeffect
Хук useEffect в React с самого начала был как микроскоп, который работал и выглядел как кувалда. Потому его и используют как кувалду даже там, где нужен микроскоп.
React 18 принёс ещё больше вопросов (отчасти ещё и потому, что документация сильно отстаёт и изначально неверна).
Так что я, конечно, настоятельно рекомендую почитать Дэна Абрамова: https://overreacted.io/a-complete-guide-to-useeffect/
Есть в переводе на Хабре: https://habr.com/ru/company/ruvds/blog/445276/
А чтобы добить знания — глянуть видео о useEffect и его современном значении и правильном применении: https://www.youtube.com/watch?v=HPoC-k7Rxwo
#react #hooks #useeffect
👍10
#инструмент дня
Не так давно команда разработчиков React выкатила статью с таким очевидным названием You Might Not Need an Effect. Я её обозревал тут: https://t.me/htmlshit/2548
Если кто не читал, очень рекомендую или её или хотя бы мой обзор.
Так вот, в ESLint присутствует правило, которое буквально повторяет статью: no-direct-set-state-in-use-effect.
Как можно догадаться, правило это явно запрещает прямой вызов setState в useEffect. Ну просто потому что в большинстве случаев это оверинжиниринг.
Как всегда, присутствуют примеры кода, которые пройдут и не пройдут условия. Может, кому-то так будет понятнее, нежели читать всю статью целиком :)
А, ну из самых популярных косяков, это использовать React/TanStack Query, получить данные, повесить на эти данные эффект и вызвать setData🫠
Не надо так, в общем.
#react #useeffect #eslint
Не так давно команда разработчиков React выкатила статью с таким очевидным названием You Might Not Need an Effect. Я её обозревал тут: https://t.me/htmlshit/2548
Если кто не читал, очень рекомендую или её или хотя бы мой обзор.
Так вот, в ESLint присутствует правило, которое буквально повторяет статью: no-direct-set-state-in-use-effect.
Как можно догадаться, правило это явно запрещает прямой вызов setState в useEffect. Ну просто потому что в большинстве случаев это оверинжиниринг.
Как всегда, присутствуют примеры кода, которые пройдут и не пройдут условия. Может, кому-то так будет понятнее, нежели читать всю статью целиком :)
А, ну из самых популярных косяков, это использовать React/TanStack Query, получить данные, повесить на эти данные эффект и вызвать setData
Не надо так, в общем.
#react #useeffect #eslint
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
#фишка дня
Это дежурное напоминание о том, что если объявить независимые и чистые функции вне контекста компонента, они не будут пересоздаваться на каждый рендер и, соответственно, вам не нужны будут ни useEffect, ни useCallback ни прочие трюки.
То есть:
Уточнение: я в курсе, что скролл нынче можно сделать в CSS, суть не в этом.
Видите, что мы сделали? Функция — чистый сайд-эффект, она не трогает никакое из состояний приложения, только его внешний вид. Нам достаточно просто ссылки.
Скролл, фокус, анимации, обращение к глобальным состояниям и шине событий — всё это можно смело выносить наружу.
Пруф: https://codesandbox.io/p/sandbox/scroll-into-view-forked-6t9ppq
Статья на тему от создателей React Query: https://tkdodo.eu/blog/avoiding-use-effect-with-callback-refs
И конечно же напоминание от команды React, что useEffect нужен далеко не всегда: https://react.dev/learn/you-might-not-need-an-effect
#react #ref #useeffect
Это дежурное напоминание о том, что если объявить независимые и чистые функции вне контекста компонента, они не будут пересоздаваться на каждый рендер и, соответственно, вам не нужны будут ни useEffect, ни useCallback ни прочие трюки.
То есть:
const scroller = (node: HTMLDivElement | null) => {
node?.scrollIntoView({ behavior: "smooth" });
};
const ChatWindow = () => {
return (
<>
{Array.from(Array(100).keys()).map((e) => (
<div key={e}>Chat message: {e}</div>
))}
<div ref={scroller} />
</>
);
};
Уточнение: я в курсе, что скролл нынче можно сделать в CSS, суть не в этом.
Видите, что мы сделали? Функция — чистый сайд-эффект, она не трогает никакое из состояний приложения, только его внешний вид. Нам достаточно просто ссылки.
Скролл, фокус, анимации, обращение к глобальным состояниям и шине событий — всё это можно смело выносить наружу.
Пруф: https://codesandbox.io/p/sandbox/scroll-into-view-forked-6t9ppq
Статья на тему от создателей React Query: https://tkdodo.eu/blog/avoiding-use-effect-with-callback-refs
И конечно же напоминание от команды React, что useEffect нужен далеко не всегда: https://react.dev/learn/you-might-not-need-an-effect
#react #ref #useeffect
👍26❤5👎1
#такое дня
12 сентября Cloudflare устроили себе эпичный автогол: https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/
В новой версии дашборда React-хук внезапно превратился в пулемёт: вместо одного вызова useEffect он триггерился десятки раз подряд. Причина до обидного банальна — в зависимостях лежал объект, который пересоздавался на каждом рендере.
В итоге фронтенд начал долбить Tenant Service шквалом запросов, сервис не выдержал нагрузки и лёг. А вместе с ним посыпалась и авторизация всех API-запросов, так что по системе пошёл массовый вал 5xx.
И это ведь не какая-то загадочная бага в ядре Linux, а ошибка из разряда «прочитай первую статью про хуки». Её должны были отловить ещё на ревью.
Но видимо, ревью формальное, нагрузочных тестов не было вовсе, а сценарии перегруза и защиты от них решили «подразумеваются».
Рекомендую прочесть статью хотя бы ради того, чтобы узнать, что такое Thundering Herd :)
Особо смешно, что индустрия уже много лет живёт с готовыми решениями этих проблем. Есть react-query, SWR и куча других библиотек, которые умеют кешировать данные, контролировать повторные запросы, дебаунсить и ретраить без того, чтобы фронтенд превращался в DoS-атаку на свой же бэкенд. Но всё это дружно игнорируется, и в прод выкатываются костыли уровня «ну вроде работает».
В итоге — глобальная недоступность сервиса, вызванная элементарным skill issue. Ошибка, которую любой толковый джун заметил бы на месте, внезапно кладёт критичную часть инфраструктуры одной из крупнейших сетевых компаний в мире.
И нет, это не React виноват, дамы и господа, даже не начинайте.
Ирония в том, что чем больше индустрия пишет о «best practices» и «production-ready», тем чаще мы видим вот такие падения на ровном месте.
#react #useeffect #hook
12 сентября Cloudflare устроили себе эпичный автогол: https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/
В новой версии дашборда React-хук внезапно превратился в пулемёт: вместо одного вызова useEffect он триггерился десятки раз подряд. Причина до обидного банальна — в зависимостях лежал объект, который пересоздавался на каждом рендере.
В итоге фронтенд начал долбить Tenant Service шквалом запросов, сервис не выдержал нагрузки и лёг. А вместе с ним посыпалась и авторизация всех API-запросов, так что по системе пошёл массовый вал 5xx.
И это ведь не какая-то загадочная бага в ядре Linux, а ошибка из разряда «прочитай первую статью про хуки». Её должны были отловить ещё на ревью.
Но видимо, ревью формальное, нагрузочных тестов не было вовсе, а сценарии перегруза и защиты от них решили «подразумеваются».
Рекомендую прочесть статью хотя бы ради того, чтобы узнать, что такое Thundering Herd :)
Особо смешно, что индустрия уже много лет живёт с готовыми решениями этих проблем. Есть react-query, SWR и куча других библиотек, которые умеют кешировать данные, контролировать повторные запросы, дебаунсить и ретраить без того, чтобы фронтенд превращался в DoS-атаку на свой же бэкенд. Но всё это дружно игнорируется, и в прод выкатываются костыли уровня «ну вроде работает».
В итоге — глобальная недоступность сервиса, вызванная элементарным skill issue. Ошибка, которую любой толковый джун заметил бы на месте, внезапно кладёт критичную часть инфраструктуры одной из крупнейших сетевых компаний в мире.
И нет, это не React виноват, дамы и господа, даже не начинайте.
Ирония в том, что чем больше индустрия пишет о «best practices» и «production-ready», тем чаще мы видим вот такие падения на ровном месте.
#react #useeffect #hook
1🤡13👍8❤5🫡1