#заметка дня

Итак, ты хочешь использовать Tanstack (React) Query для запроса данных, но хочешь делать это по-запросу, а не декларативно?

Ни слова больше! Используй useMutation, даже если это контр-интуитивно. Мутации — они по своей природе императивные, их нужно вызывать ручками в нужный момент.

Вот только есть один нюанс: мутацию — опять же, по-определению — нельзя отменить. Если требование изменений ушло на сервер — слишком много телодвижений нужно, чтобы перестать это делать. Нет уверенности в том, что изменения ещё не применились.

Да, даже если мутация, на самом деле, ничего не делает.

А мне надо было, стояла задача подключаться к источникам данных, но иметь возможность это подключение (или несколько) прекратить в любой момент без создания, собственно, токена.

А вот запрос — отменить можно. Прямо в документации: или посылая AbortSignal, или вызывая соответствующий метод клиента, cancelQueries, по ключу запроса.

С мутацией сильно больше телодвижений.

Кстати, вы же в курсе, что ключи действуют как wildcard? todo среагирует и на todo-1, и на todo-2 и так далее. Это не самая очевидная вещь.

Ладно, но всё же, как вызвать запрос императивно?

Очень просто: комбинацией из refetch и параметра enabled в конфигурации хука:

useQuery<TokenResponse>({
    enabled: false,
    retry: false,
    refetchOnReconnect: false,
    refetchOnWindowFocus: false,
    refetchInterval: false,
    queryKey: ['connecting', dsId, connectionKey],
    queryFn: async ({ signal }) => {
         signal?.addEventListener('abort', cancelConnection);
          ...
     }
});

И используем как обычно:

const {
    data: profile,
    refetch: startConnection,
    connectionStatus,
    isFetching: isFetchingConnection,
    isError,
} = useConnect(dataSource, ...);

Секрет в том, что теперь refetch можно передать куда угодно и дёрнуть.

Естественно, всегда создавайте кастомные хуки для useQuery и useMutation. Не держите логику в компоненте.

Я ещё люблю отключать refetch по фокусу на окне и по потере соединения. Про идиотскую ситуацию с неправильным определением потери соединения я уже писал ранее.

#react #tanstack #query #бородач

#презентация дня

Я тут сегодня успел на митапе побывать! И не просто побывать, а ещё и спикером там был.

Митап — Design System Breakfast, который лидит Варя Степанова — посвящён, как несложно догадаться, дизайн-системам в разных их проявлениях. И сегодня я там презентовал открытую мной недавно возможность писать функциональные и поведенческие тесты прямо в сторях, а потом запускать их в Jest как локально, так и в CI/CD.

И называется эта вся прелесть — Storybook Interactions. И, естественно, одним только Jest дело не ограничивается, скорее даже наоборрот — официальная их рекомендация это использование Vitest и Playwright. Но у нас в команде уже есть сформированная экосистема.

Итак, презентация: https://docs.google.com/presentation/d/1hpAt3y4zE1U8vRhY_IfmM3NEeY8qCe9QdKnQLAJF8oo/edit?usp=sharing

Ну и, конечно же, пример на гитхабе: https://github.com/bekharsky/when-jest-met-storybook

Стек: Vite, React 19, MSW, MUI, React Router, Tanstack Query, Storybook 9 и Jest с SWC.

Если нужно больше подробностей или хотите стрим прямо здесь на канале — требуйте, не стесняйтесь, котаны!

#react #design #storybook #ui #test

#молния дня


В React обнаружили критическую уязвимость в механизме серверных компонентов (React Server Components). Из-за ошибки в том, как React разбирает входящие данные, сервер может попытаться выполнить вредоносный объект как часть своей логики. Достаточно специально подготовленного HTTP-запроса — и код на сервере окажется под контролем не того, кто его писал.

Это не проблема конкретного фреймворка. Под удар попадает любой проект, где используются RSC: Next.js, Remix (с RSC-вставками), любые кастомные серверные интеграции, экспериментальные рантаймы, кастомные бандлы — неважно. Если у вас есть React Server Components, риск реальный.

Уязвимы версии пакетов react-server-dom-* — 19.0.0, 19.1.0, 19.1.1, 19.2.0.
Официальное описание: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components

Next.js упоминают чаще всего просто потому, что он массово использует RSC «из коробки», и поэтому количество уязвимых приложений там особенно велико. Но это не его эксклюзивная проблема — это дыра именно в React.

Патчи уже вышли: React закрыл её в версиях 19.0.1, 19.1.2, 19.2.1.

Если у вас Next.js, то актуальные безопасные релизы: 15.0.5+ и 16.0.7
(детали: https://nextjs.org/blog/CVE-2025-66478)

Суть в том, что если ваш сервер хоть как-то отдаёт RSC-ответы и принимает RSC-запросы, обновиться нужно обязательно. Если серверных компонентов нет — пофигу.

Кстати, вот и технический разбор как проблемы, так и патча: https://www.ox.security/blog/rce-in-react-server-components/

#react #rsc #next

#статья дня

Зачем писать код, если можно сгенерировать, правда? Такие нынче правила игры. Но нужно идти дальше.

Зачем писать код, если можно украсть? Особенно, когда сам в руки идёт. Ведь если даже генерировать что-то, нужно, как минимум, учитывать требования по работе, дизайну... никто не отменял понимание сути задачи.

Так вот, сегодня на поветске дня — как украсть любой React-компонент!

И в этом нам поможет React DevTools, любая сносная LLM-ка и вот эта инструкция: https://fant.io/react/

TL;DR
React-приложение хранится не только в DOM-представлении, но и в виде React Fiber — внутреннего дерева (тот самый виртуальный DOM), где видно, какой компонент и с какими пропсами создал разметку.

Все экземпляры одного компонента ссылаются на один и тот же т. н. type, поэтому можно сгруппировать их и собрать реальные примеры прямо из продакшена.

Эти примеры вместе с минифицированным кодом компонента скармливаются LLM, которая восстанавливает чистый React. Дальше идёт проверка: компонент рендерится с теми же пропсами, HTML сравнивается с оригиналом, а расхождения отправляются обратно модели. Компоненты собираются снизу вверх, от простых к составным. Анимации и сложные состояния чуток могут замедлить процесс, но для статичного UI он работает прям хорошо.

Дивный новый мир. А чтобы понимать внутренности Fiber, можно использовать инструмент со странным названием bippy: https://github.com/aidenybai/bippy, когда, что и почему отрендерилось.

#react

#такое дня

Я уже как-то участвовал в нескольких спорах на тему того, что TUI — text-based ui interface — это не больше чем фишечка, такой себе ретрофутуризм.

Ведь каждому очень хочется себя почувствовать хакером из фильмов, если уж до интерфейсов Джарвиса из Железного Человека мы пока не доросли.

Впрочем, как мне справедливо заметили: «А минусы будут?», — да может и нет их...

Но что бы вы думали, взорвавший популярность TUI в последние пару лет Claude Code будет написан на условном C или Python?

Наверное, как сорок лет назад Vim, Emacs и среды Borland Turbo? Ну или ncurses на худой конец там, ведь проблема вывода текста кажется давно решённой?

Нет, там React :) Они рендерят сцену целиком, а потом процессят вьюхи чтобы вывести их текстом, предварительно сравнивая с предыдущим рендера.

Зачем? Да никто не знает, захотелось парням, кто мы такие, чтобы их судить.

Просто экран клода так и будет продолжать мерцать. Обещают, что чуть поменьше, чем раньше. Ведь 16ms на фрейм им теперь хватает с трудом.

Выводов не будет, нет никаких сил. Просто по ссылкам в посте пройдите, там достаточно интересно.

#claude #react

#такое дня

Люди в LinkedIn, конечно, странные. Удивительно, что useEffect и use ничему его не научили в продажах. Но не суть.

А суть в том, что ребята из React, конечно, как продолжали вносить смуту и вытаскивать наружу внутренние особенности реализации, так и продолжают. И никакие You Might Not Need an Effect тут уже не помогут.

Но вообще, конечно, просто смешная картинка. Ведь очевидно, что нужно использовать Effector React Query.

#react #thoughts

#заметка дня

Иногда стоит выкладывать рекламу, чтобы просто увидеть, что вы живы, котаны. На посты такого количества реакций никогда нет.

А тема сегодняшней заметки — очередная статья на тему «Нам не нужен useEffect»: вот тут.

В чём же проблема таких статей? Да на самом деле проблемы-то особой и нет, есть некоторая недосказанность.

И недосказанность эта связана с тем, что ВСЕ ваши прекрасные библиотеки управления состоянием, анимацией, загрузкой данных и кешем — будут использовать useEffect внутри себя. И говорить, что вы отказываетесь от useEffect — не очень верно.

Что верно, так это то, что их имплементация будет просто намного лучше протестирована. Ну, возможно.

Тем не менее, самый любимый пример, когда отказ от useEffect действительно имеет смысл — на иллюстрации.

Суть проста: если ваше действие требует полной перезагрузки логики, перерисовки компонента — так перерисуйте, блин, компонент, а не пытайтесь через useEffect чота там стартануть.

Продублирую текстом:

// ❌ BAD: Effect attempts to emulate remount behavior
function VideoPlayer({ videoId }) {
  useEffect(() => {
    loadVideo(videoId);
  }, [videoId]);
}

// ✅ GOOD: key forces clean remount
function VideoPlayer({ videoId }) {
  useMountEffect(() => {
    loadVideo(videoId);
  });
}

function VideoPlayerWrapper({ videoId }) {
  return <VideoPlayer key={videoId} videoId={videoId} />;
}

Это настолько чисто, элегантно и понятно — что удивляешься, почему это не стало общим паттерном.

Впрочем, дело за вами, котаны.

#react #useeffect #article

#статья дня

GitHub выкатил отличный пост о том, как они ускоряли рендеринг диффов в пулл-реквестах (исконно русские слова) — и внезапно выяснили, что браузеру становится плохо, когда в PR десятки тысяч строк.

Вот ссыль сразу: https://github.blog/engineering/architecture-optimization/the-uphill-climb-of-making-diff-lines-performant/

Главная проблема оказалась в том, что каждая строка diff-а была маленьким React-стартапом: 8–13 компонентов, куча DOM-нод и отдельные event handlers почти на всё подряд.

Старый подход выглядел примерно так:

<DiffLine>
  <LineNumber />
  <SyntaxHighlight>
    <Token />
    <Token />
  </SyntaxHighlight>
</DiffLine>

И конечно же:

<div
  onMouseEnter={...}
  onMouseLeave={...}
  onClick={...}
/>

Когда таких строк 10 000+, Chrome начинает потреблять память не в себя.

А дальше случилось прекрасное: GitHub героически переоткрыл event delegation — технику, которую jQuery нормально объяснял ещё лет 15 назад (не воспринимайте буквально, автоматическая делегация в реакте была и есть). Оказалось, что один обработчик событий на контейнер внезапно быстрее, чем 30 тысяч onMouseEnter на каждую строку. Кто бы мог подумать.

Новый вариант:

<table onMouseMove={handleHover}>
  <tr data-line="42">
    <td>const value = 1;</td>
  </tr>
</table>
function handleHover(e) {
  highlight(e.target.dataset.line)
}

В итоге GitHub выкинул 74% React-компонентов, почти вдвое снизил потребление памяти и ещё удалил пару лишних <code>-тегов из каждой строки, потому что 20 000 ненужных DOM-элементов — это всё ещё 20 000 ненужных DOM-элементов.

Мораль истории максимально простая: abstraction is not free. Иногда один обработчик событий и туповатый плоский код работают лучше, чем архитектура мечты из 400 reusable-компонентов, custom hooks и трёх уровней composition.

#github #react #virtualization

#статья дня

Я тут в нашем продукте всё пытаюсь сделать идеальные всплывающие уведомления, aka тосты.

Потому что выскакивают, как хлеб из тостера.

Поначалу они были сугубо императивные, вызвали уведомление вручную, вручную же скрыли все разом или по некому id. Потом я решил объединить уведомления и некоторые виды модальных окон (например, подтверждение или отмену действия).

Параллельно я начал переписывать императивные уведомления на React, потому что на тот момент приложение стало гибридным. Получалось вроде неплохо. Но в какой-то момент...

В какой-то момент я на полную познал, что такое гипотеза Чёрной Королевы (забавно, что в английском языке — Красной Королевы). В простейшем варианте она звучит так: "Нужно бежать, чтобы оставаться на месте". Непомерно много усилий требуется, чтобы лишь чуть-чуть двигаться вперёд.

В мире разработки она же значит, что на один закрытый баг — получаешь пятнадцать новых :)

Да, пришло время признать, что я со своей реализацией уведомлений зашёл в тупик, и надо смотреть в сторону альтернатив.

И тут попадается нечто прекрасное, компонент Sonner: https://emilkowal.ski/ui/building-a-toast-component

И сразу ссылка на репозиторий: https://github.com/emilkowalski/sonner

Статья буквально на острие взаимодействия CSS и JS, объяснены принципы построения анимаций на CSS-переменных и управления ими из React-приложения.

Сами же тосты реализованы на простой шине событий, что весьма надёжно.

В общем, я ещё свой поиск идеальной реализации не завершил, но Sonner — максимально к ней близок.

#react #toasts #notification #animation #бородач

#релиз дня

Вышел React 19.3, и на этот раз в релизе есть несколько вполне заметных вещей.

Главное — две экспериментальные фичи наконец стали стабильными:

— <ViewTransition> — React теперь умеет нормально работать с браузерным View Transition API: enter/exit/update/shared-element анимации, интеграция с Suspense, свои переходы.

— refs на <Fragment> — можно получить доступ к группе DOM-элементов без лишнего wrapper-div: повесить event listener, IntersectionObserver, управлять фокусом, вызвать scrollIntoView() и т.д.

Ещё появилась довольно приятная мелочь для SSR:

use(browser())

Компонент таким образом можно явно исключить из серверного рендера. На сервере он уйдёт в ближайший Suspense, а в браузере продолжит рендериться как обычно. Никаких typeof window !== 'undefined' и mounted через useEffect.

Плюс React теперь поддерживает Trusted Types. Это браузерная защита от DOM XSS: через CSP можно запретить передавать обычные строки в опасные API вроде innerHTML и разрешать только заранее проверенный TrustedHTML. Раньше React такой объект превращал обратно в строку и ломал механизм. В 19.3 trusted-значения наконец проходят в DOM как есть.

Штош, мне нравится этот островок стабильности.

https://react.dev/blog/2026/09/09/react-19-3

#react