#инструмент дня

Охренеть какая штука!

https://react-explorer.com/

Это обозреватель зависимостей. Я бы даже сказал, созвездия завимимостей и сейчас вы поймёте, почему.

Потому что помимо простого дерева, которое в целом умеет строить кто угодно, тут имеется мини-карта!

Перемещаешься по карте — смотришь подсвеченные созвездия. Инспектор работает на любом реакт-сайте без отдельной установки, потому что построен по принципу React Scan — инджектит React DevTools на страницу.

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

Проект пока не открыт, но находится в открытом тестировании.

#react #analyze #dependencies

#заметка дня

Не знаю, как вас, но меня очень раздражает то, что в React Router состоянием скролла надо управлять самостоятельно.

Перемещаешься по роутам, а скролл на месте остаётся. Ну типа, што.

К счастью, решение что для v5 React Router, что для v6 одинаковое:

function ScrollToTop() {
    const { pathname } = useLocation();

    useLayoutEffect(() => {
        document.documentElement.scrollTo(0, 0);
    }, [pathname]);

    return null;
}

И потом вставляете его в контекст роутинга:

<BrowserRouter>
    <Routes>
         ...
    </Routes>
    <ScrollToTop/>
</BrowserRouter>

Но вот я это всё по привычке написал и решил всё-таки посмотреть документацию. Ну бывает. И вот что там: https://reactrouter.com/en/main/components/scroll-restoration

Восстановление скролла теперь поставляется из коробки! И умеет гораздо больше, чем просто скроллить наверх. Правда, требует изменения корневого роутера. Благо, это несложно.

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

По-моему, очень круто. И хорошо, что решение официальное.

#react #router #бородач

#инструмент дня

Вы только посмотрите на эту красоту!

Да, я в курсе, что компонентов для красивого прокручивания цифр у нас какое-то невероятное количество, но до сих пор не было ничего настолько универсального и простого в использовании.

И не только для React! Vue и Svelte тоже там.

Итак, встречайте: NumberFlow от Максвелла Барвиана.

GitHub: https://github.com/barvian/number-flow
Документация и демо: https://number-flow.barvian.me/

Настраивается формат чисел, параметры анимированных переходов. И, собственно, никаких скрытых зависимостей.

Прекрасное.

#react #number #transition #бородач

Дэн «наше всё» Абрамов разродился статьёй!

React for Two Computers

— Почему мой компонент работает в браузере, но не на сервере?
— Потому что у тебя теперь два компьютера. Привыкай.

💥 Что вообще происходит?

Раньше React жил в браузере и радовался жизни: всё происходило на клиенте, стейт в useState, кликнули — перерендерили.

А теперь у нас появился второй «компьютер» — сервер. С серверными компонентами, приватными API, тяжёлыми вычислениями и всем остальным. И теперь React — это не просто `f(state)`, а f(data, state), где:

- data — с сервера, рендерится один раз
- state — в браузере, реагирует на действия пользователя

🧠 React теперь работает в двух мирах:

- Сервер — отвечает за данные, безопасность и тяжёлую работу
- Клиент — за мгновенные отклики, интерактив и состояние

Они живут в разных средах, но должны строить один интерфейс. И вот тут начинается веселье.

🧩 Но в чём подвох?

Абрамов говорит прямо: разделение компонентов на клиентские и серверные — это боль.

- Хочешь использовать хук? Прости, сервер не умеет
- Хочешь загрузить данные? Сервер умеет, но клиент не должен знать как
- Хочешь просто написать код? Удачи с этими use client, use server, границами, пропами и тайпингом

🧠 Примеры из статьи

- <Counter /> — типичный клиентский компонент. Быстрый отклик, стейт, интерактив
- <PostPreview /> — серверный. Может грузить пост из базы и вообще не попадать в бандл клиента

И вдруг возникает челлендж: а как показать список <PostPreview />, а рядом <Counter /> для лайков? Как они будут жить вместе?

Ответ: через пропсы, границы, и много боли.

📦 React как Lego из серверных и клиентских кусочков

Абрамов не просто жалуется — он исследует. Он пытается найти модель мышления, при которой:

- Ты не дублируешь код
- UI остаётся отзывчивым
- Компоненты переиспользуемы
- И при этом ты не хочешь сжечь проект через неделю

Он говорит: возможно, будущее React — это когда мы думаем не в терминах "компоненты", а в терминах "где этот кусок должен жить?"

🎥 Есть и видео!

Если лень читать или хочется живого контекста — Дэн рассказал всё это на конференции React Conf 2024.
Там много примеров и визуальных пояснений.

🧨 Финалим

«React теперь не просто библиотека для UI. Это **координация между двумя средами исполнения**. Между клиентом и сервером. И это сложно. Но в этом сила.»

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

🔗 Читать статью целиком

📺 Смотреть видео React Conf 2024

#react #frontend #абрамов #servercomponents

#инструмент дня

Так вышло, что в своей карьере я умудрился поработать в компании, которая хотела сделать стримы на веб-сайте своей основной фишкой. С тех пор HLS, RTP и nginx-rtmp-plugin были моими друзьями.

Но возможности по микшированию видео, звука и изображений прямо на веб-странице тогда были весьма ограничены или просто сложны. Работали через OBS, хотя даже он был в весьма зачаточном состоянии.

Но сегодня я наткнулся на нечто прекрасное: https://compositor.live/

Это набор React-компонентов и медиасервер, который позволяет стримить видео и микшировать несколько потоков, управляя ими как обычными компонентами и элементами страницы!

Можно построить нечто аналогичное Google Meet за считанные дни.

Вырезать зелёный экран, добавить текст, поменять видео местами, наложить блупер — всё на месте. Напоминает react-three-fiber по своей сути.

#react #video #mixer #media #stream #бородач

#статья дня

Дэн наше всё Абрамов недавно написал статью о новом способе передачи данных с сервера — Progressive JSON. Это не просто использование курсоров для пагинации, как в том же JSON:API, а настоящий поток данных, где структура JSON передаётся частями, по мере её готовности.

Вообще, много пишет последнее время. Это хорошо!

Зачем нужно? Собственно, для работы React Server Components в том числа!

Пример такого потока:

{
  "header": "Welcome to my blog",
  "post": "$1",
  "footer": "Hope you like it"
}

Видите заглушку $1? Позже — в том же потоке! — приходит следующий кусок:

/* $1 */
{
  "content": "This is my article",
  "comments": "$2"
}

На стороне клиента это будет выглядеть как:

{
  "header": "Welcome to my blog",
  "post": {
    "content": "This is my article",
    "comments": new Promise(/* ... not yet resolved ... */),
  },
  "footer": "Hope you like it"
}

Комментарии в статье подгружаются по мере их поступления, и клиент может начать отображать контент сразу, даже если не все данные ещё доступны. Этот подход позволяет эффективно загружать и рендерить сложные интерфейсы, улучшая отзывчивость приложения.

Если вам интересна тема оптимизации загрузки данных, стоит прочитать статью Дэна: Progressive JSON.

А, или посмотреть в формате видеоподкаста! Тут: https://www.youtube.com/watch?v=MaMQLNBZz64

#react #json #rsc

#статья дня

Можно ли заменить стейт-менеджеры — простым localStorage?

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

Давайте подумаем:

> Не всё должно быть постоянным. Допустим, у тебя открыто модальное окно. Перезагрузил страницу — и оно снова открыто, потому что значение сохранилось в localStorage. Абсурдный UX.

> Нет реактивности. Если просто читать из localStorage, React не узнает, что данные изменились, и не перерендерит компонент. Придётся вручную дёргать setState.

> Событие storage работает не так. Оно срабатывает только в других вкладках, а не в той, где ты вызвал localStorage.setItem(). То есть синхронизацию внутри приложения оно не решает.

> Ограничения. Только строки, лимит около 5 МБ, возможные ошибки при парсинге JSON, коллизии ключей. Всё это требует дополнительных костылей.

> SSR недоступен. На сервере localStorage просто не существует, и код падает с ошибкой.

localStorage и, частично, sessionStorage отлично подходят для мелочей:

> выбор темы,
> сохранение введённых данных формы,
> открытая вкладка меню,

Но как только речь заходит о данных, которые должны синхронно обновляться в разных компонентах и вызывать ререндер — нужен Context или полноценный state-менеджер.

Итак: localStorage — это удобное дополнение к Context/Redux/Zustand, но не замена. Он решает задачу «сохранить между сессиями», а не «синхронизировать состояние внутри React».

А если хотите подробностей — собственно, статья от Нади Макаревич: https://www.developerway.com/posts/local-storage-instead-of-context

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

#react #localstorage

#фишка дня

И #тред дня, и #статья дня... Сегодня всё и сразу от Джоша Комо.

И речь пойдёт о недооценённом хуке в React: useDeferredValue.

Итак, некоторое время назад Джош выпустил свой инструмент для создания красиво выглядящих теней (да-да, drop-shadow просто уже недостаточно). И одной из проблем инструмента стала... дёрганая реакция на движение ползунков. Как будто мало FPS.

Начав разбирать проблему, Джош понял, что событие onChange происходит очень часто, за это время надо успеть сгенерировать тень, потом отрисовать её, потом вставить код в редактор для копирования. А редактор, естественно, ещё пытается этот самый код подсветить.

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

И именно для этого и нужен хук useDeferredValue. Данные молучим только когда основной процесс рендеринга завершится. Буквально ленивое выполнение.

Собственно, тред и статья если кто предпочитает подробности. Там, как всегда, шикарно.

Будьте разумно ленивыми, котаны!

#react #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

#зомби дня

Sanity написали про текущее состояние styled-components.

Библиотека официально с марта, если помните, в maintenance-режиме: новых фич ждать не стоит, и главная проблема — производительность. В React 18 она не использует useInsertionEffect, из-за чего вставка стилей тормозит рендер. И это ощутимо.

В Sanity сделали форк и оптимизировали вставку стилей, убрали лишние костыли и адаптировали всё под React 19. У Linear, после замены пакета на этот форк, рендер ускорился до 40% без переписывания компонентов.

Для React 18 они предлагают @sanity/styled-components, для React 19 — @sanity/css-in-js.

При этом авторы подчёркивают, что форк — временное решение. В ближайшей перспективе они советуют перестать писать новые компоненты на styled-components и выбрать альтернативу вроде vanilla-extract, Tailwind или Panda CSS, постепенно перенося стили.

Учитывая, что у нас в компании ещё огромное количество зависимостей от Styled Components (ведь все в целом ждали несколько иного развития событий), переход на форк, чтобы сгладить ситуацию во время апгрейда на React 18 и 19, кажется разумным. Тем более, что текущее состояние старых компонентов давно заморожено.

#css #react #sc